[00:00:02] <bunder> but my fragmentation
[00:00:12] <bunder> :)
[00:01:25] *** rich0 <rich0!~quassel@gentoo/developer/rich0> has joined #zfsonlinux
[00:02:36] *** rich0 <rich0!~quassel@gentoo/developer/rich0> has quit IRC (Remote host closed the connection)
[00:03:29] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has quit IRC (Quit: shibboleth)
[00:03:42] <ptx0> bunder: that's how i was thinking it'd look
[00:03:49] *** IonTau <IonTau!~IonTau@203-206-42-171.dyn.iinet.net.au> has joined #zfsonlinux
[00:05:13] *** rich0 <rich0!~quassel@gentoo/developer/rich0> has joined #zfsonlinux
[00:06:51] <bunder> s/used/taken ?
[00:07:22] <ptx0> yeah that's what my brain jumped out at but that's the original wording
[00:07:40] <ptx0> i'll update it though
[00:11:39] <PMT> vzvol?
[00:12:12] <bunder> hmm, i thought we got fast clone delete already
[00:12:54] <bunder> guess not
[00:14:45] <PMT> I believe there's a PR
[00:15:03] <PMT> Oh, hm, apparently there wasn't before, lmao.
[00:18:28] *** Hypfer <Hypfer!~Hypfer@unaffiliated/hypfer> has quit IRC (Ping timeout: 268 seconds)
[00:19:04] *** digrouz <email@example.com> has quit IRC ()
[00:19:53] <cirdan> heh. <@dvl> optiz0r: There's this guy posting on the mailing lists... ~10PB on tape
[00:20:14] <bunder> on one tape?
[00:20:26] <cirdan> ...yes, one tape
[00:20:44] <bunder> is that even possible?
[00:20:52] <cirdan> sure
[00:20:56] <ptx0> ZLE
[00:20:58] <cirdan> wanna buy one?
[00:21:07] <cirdan> ill sell
[00:21:16] <cirdan> >:-D
[00:21:36] <Shinigami-Sama> thats compressed size or uncompressed size?
[00:21:43] <cirdan> yes
[00:23:23] <jasonwc> ptx0: I'm going to try to replicate the data corruption you experienced with incremental encrypted sends. You note the command you used was "`zfs send -Rwv rpool/ocean@to_newjack | zfs recv -Fv newjack/ocean`". You describe this as an "incremental" send but it just looks like a replication stream of all snapshots through the snapshot specified. I thought "incremental" only applied if
[00:23:23] <jasonwc> you used -i or -I.
[00:23:57] <ptx0> nah
[00:24:03] <ptx0> send -R is incremental if it includes >1 snapshot
[00:24:28] <ptx0> it sends a full stream and then differences
[00:24:50] <jasonwc> The man page indicates it's only incremental if -I or -i is used, but I see your point.
[00:27:16] <ptx0> i mean, use zstreamdump
[00:27:20] <ptx0> you can see it is incremental
[00:27:54] <ptx0> i was trying to narrow it down to what causes the IO error and any operation with an internal or otherwise incremental raw recv does it
[00:28:04] <jasonwc> Do you think there's something special about sending a root pool with lots of snapshots that caused this corruption or would any data suffice?
[00:28:11] <ptx0> it doesn't need -R, but -w -I will do
[00:28:30] <ptx0> tom says he can't reproduce it
[00:29:46] <jasonwc> ok
[00:30:55] <cirdan> ptx0: was it limited to a specific pool?
[00:31:16] <cirdan> maybe it's just a tr bug :)
[00:31:20] <ptx0> nope
[00:31:27] <ptx0> recv side is a xeon
[00:31:41] <ptx0> happens on both systems
[00:46:56] <jasonwc> ptx0: So, I did a fairly simple test. I created two pools. In the first pool, testpool, I created an encrypted dataset and downloaded kernel 4.19 from kernel.org which I extracted in the same dataset. I then created a snapshot, snap1. I then downloaded kernel 5.0-rc6 and did the same thing. I then created snap2. I then did 'zfs send -Rwv testpool/encryptedtest@span2 | zfs recv -Fv
[00:46:57] <jasonwc> testpool2/encryptedtest. I then scrubbed both pools. No errors.
[00:47:25] <ptx0> scrub doesn't report anything, you need to load the recv filesystem key
[00:47:29] <PMT> bunder: even with custom fabrication, a tape that dense would currently be a fool's venture.
[00:47:32] <Shinigami-Sama> maybr ptx0's porn does somethign weird
[00:47:35] <jasonwc> I'm confused by the fact that you say, "I scrub once a week, which some consider excessive, but it never reports any data issues." but the warning/errors shows a zpool scrub that showed permanent data errors
[00:47:35] <ptx0> and then actually read the files
[00:47:58] <ptx0> the key is typically unloaded, jasonwc
[00:48:03] <cirdan> PMT: its 654mi long
[00:48:06] <Shinigami-Sama> PMT: shingled tape :D
[00:48:14] <ptx0> scrub won't find errors in unloaded and untouched data structures
[00:48:20] <ptx0> i guess that's a good point
[00:48:27] <ptx0> it is something being unwrapped improperly, maybe.
[00:48:41] <jasonwc> the key is loaded since I didn't export the pool
[00:48:56] <jasonwc> would running find be sufficient?
[00:48:56] <DHE> I scrub my enterprise drives weekly because they arrived having either been dropped by the shipper or a catastrophically bad manufacturing batch.. :/
[00:49:00] <ptx0> i raw recv encrypted datasets into 'unencrypted pool'
[00:49:03] <PMT> Shinigami-Sama: christ, no
[00:49:22] <cirdan> DHE: every 2 weeks here at home cause why not?
[00:49:31] <jasonwc> same, every 2 weeks
[00:49:35] <ptx0> jasonwc: fwiw it doesn't occur immediately on my system either, i can set up a fresh rootfs pool and use it for weeks without issue
[00:49:38] <DHE> cirdan: I am genuinely concerned for the health of these disks. that's why I do it.
[00:50:06] <ptx0> tom should set up a script that continuously sends/recvs and loads the dataset to verify the file contents inside
[00:50:15] <cirdan> DHE: yeah i know i just mean even if not it's not generally too hard to do
[00:50:58] <DHE> there's still a performance hit...
[00:51:31] <ptx0> DHE: but it says drop ship
[00:51:44] <cirdan> hmm question: does smart's uncorrectable sectors attribute work on physical or logical? i have a drive with 8 sectors pending so it would seem that it could be talking about logical sectors
[00:51:47] <DHE> *snort*
[00:51:57] <cirdan> also zfs reports no errors oddly
[00:52:09] <DHE> cirdan: the disk runs in physical sectors. that's how they work
[00:52:12] <PMT> cirdan: Pending Sectors are "if you overwrite the contents of them we remap them from spares"
[00:52:20] <jasonwc> ptx0: I ran a find operation after loading the key for new encrypted dataset and there was no issues. I can try doing an rsync of the data, which will read all of the files.
[00:53:02] <cirdan> PMT: pending means we got a crc error reading it
[00:53:13] <jasonwc> ptx0: So, if as you say, scrub finds no errors, the corruption isn't from the send/recv. It's from whatever happens after that.
[00:53:14] <ptx0> jasonwc: like i said, i had an encrypted dataset and it was fucked on recv side, but i was able to then send without -p, -R, or -w, and 'recreate' the filesystem into a fresh 'zfs create -o encryption=on' encryptionroot
[00:53:31] <cirdan> itll clear if the sector can be read or if it's overwritten
[00:53:33] <PMT> cirdan: yes, which means it got marked as "okay next time it's overwritten we mark it as Offline_Uncorrectable and remap that logical address to a spare sector."
[00:53:36] <ptx0> it was then okay and i was able to recv this and load that dataset key without issue
[00:53:45] <PMT> Or if it successfully reads.
[00:53:49] <ptx0> so, something on the source dataset is mangled in a way that the recv side chokes on
[00:54:04] <ptx0> and over time it will get mangled again in the same way
[00:54:05] <cirdan> it only goes to Offline_Uncorrectable if it can't be written to and read right back
[00:54:18] <PMT> Source?
[00:54:39] <jasonwc> ptx0: Does it matter whether the key is loaded in terms of what scrub is doing? I assume it'll just read the data and verify it against the checksum which doesn't require decryption.
[00:56:16] <DHE> I don't dictate what the vendor ships with
[00:56:56] <ptx0> jasonwc: no idea
[00:58:23] <jasonwc> ptx0: So, I loaded the encryption key, mounted the encrypted dataset, and then did rsync -arv from the encrypted dataset to a new dataset to see if it would give any checksum or IO errors. Rsync completed and zpool status shows no errors.
[00:58:48] <PMT> jasonwc: fyi -a implies -r
[00:59:01] <ptx0> yeah, that simple test is not going to reproduce the issue
[00:59:19] <ptx0> you need to run an encrypted rpool with real data that's been written/rewritten/snapshotted over time
[00:59:26] <jasonwc> ah, ok
[00:59:51] <ptx0> i have rpool unencrypted, rpool/ocean as encryptionroot for all children incl home, rootfs
[01:03:26] <jasonwc> That might explain why nobody else has reported this. In order to use encryption for a root pool, you would need an unencrypted boot pool if using Grub, since Grub won't work if encryption=on on the dataset, at least that's my understanding.
[01:03:40] <ptx0> it's not uncommon
[01:05:15] <jasonwc> It isn't? A large number of people are using a testing branch of ZFS to run their root pools with a feature that has had several on-disk format changes, causing the need to recreate datasets?
[01:05:37] <ptx0> i think you're overstating the issues, which occurred a year ago now
[01:05:54] <PMT> A concerning number of people run git builds on their stable systems.
[01:06:06] <PMT> But then, I'm boring about things like that. :P
[01:06:17] <Shinigami-Sama> git head is stupidly stable
[01:06:24] <jasonwc> PMT: Yeah, I've never run a non-stable release on my production systems, just VMs
[01:06:34] <jasonwc> I assume it'll eat my data
[01:08:42] <cirdan> om nom nom nom
[01:11:32] <jasonwc> Anyone else here running an encrypted rpool with the native encryption?
[01:11:34] <PMT> Shinigami-Sama: it turns out that's true whether you think it's stable or unstable
[01:12:24] <jasonwc> What is?
[01:12:44] <jasonwc> That you should assume it'll eat your data?
[01:13:16] <PMT> jasonwc: the description was "stupidly stable", which could either be taken as ridiculously stable or extremely unstable
[01:13:30] <Shinigami-Sama> :D
[01:13:55] <jasonwc> ah
[01:14:03] <PMT> My general advice is to not run unstable code on production systems unless you're paying people to fix it when it catches fire. :)
[01:15:28] <jasonwc> man, Trump's speech today sound like it was created by a random word generator
[01:16:09] <PMT> s/today sound/sounds/
[01:17:15] <jasonwc> thanks :)
[01:37:18] <Shinigami-Sama> I wasn't kidding about he 300 more
[01:38:12] *** jugo <jugo!~jugo@unaffiliated/jugo> has quit IRC (Ping timeout: 250 seconds)
[01:40:16] *** jugo <jugo!~jugo@unaffiliated/jugo> has joined #zfsonlinux
[02:04:15] *** AllanJude <AllanJude!ajude@freebsd/developer/AllanJude> has joined #zfsonlinux
[02:21:48] <jasonwc> I built ZoL master using the howto instructions. Even after enabling the systemd units, they don't appear to start correctly. They show status "inactive (dead)." Not sure what's going on - they just work using the Debian packages
[02:22:10] *** c3-Linux <c3-Linux!~c3r1c3-Li@ip72-211-81-173.no.no.cox.net> has quit IRC (Remote host closed the connection)
[02:22:53] *** c3r1c3-Lin <c3r1c3-Lin!~c3r1c3-Li@ip72-211-81-173.no.no.cox.net> has joined #zfsonlinux
[02:24:47] <bunder> maybe debian's packaging does more, not sure
[02:24:57] <bunder> every distro does things a little differently
[02:25:52] <jasonwc> Yeah, the last time I built ZoL packages, I had issues with the systemd units as well. In that case, I think it wasn't installing them at all. It seems to install them, but they aren't working properly. Oh well, this is just a test VM. Not a big deal.
[02:28:27] <bunder> it sounds like you might have to remove and readd them into systemd
[02:51:08] <bunder> wew another trim pr
[02:51:33] <jasonwc> So, it appears that compressratio and refcompressratio don't account for padding due to minimum block size. Matt Ahrens mentioned this before but I wasn't sure if it was ever fixed.
[02:51:36] <jasonwc> bunder: Thanks
[02:52:24] <bunder> did i fix it? :)
[02:54:57] <jasonwc> bunder: trying now
[02:55:02] <bunder> ah
[02:55:11] <jasonwc> Yes
[02:55:30] <jasonwc> Previously, it wasn't importing my pools. I just reenabled every service, rebooted, and now it's imported
[02:55:38] <bunder> nice
[02:55:42] <jasonwc> and zed is running
[02:56:07] <jasonwc> Is there some difference between systemctl enable and systemctl reenable?
[02:57:46] <jasonwc> that's an easy fix :)
[02:58:37] <bunder> no idea, i'm an openrc guy
[02:59:19] <cirdan> yeah sudo apt-get remove --purge --burn-with-fire systemd* on every system I setup :)
[02:59:29] <jasonwc> lol
[02:59:34] <cirdan> i do
[02:59:38] <cirdan> even on raspbian
[03:01:23] <cirdan> seriously, I have no need or desire to fight with that landfil-fire
[03:01:41] <bunder> but they need to get the bugs ironed out before i consider trying it
[03:01:53] <cirdan> sysvinit does everything I need it to do and has never failed me, nor caused my system to not boot/reboot, a single time
[03:03:09] <cirdan> no worries with having /var on a dataset, or scroll lock on when I reboot, or "debug" on the kernel line, etc
[03:04:56] <jasonwc> Why did all the distros adopt something that seems universally loathed?
[03:05:05] <bunder> because redhat
[03:05:31] <DeHackEd> because systemd's purpose in life is to make other software depend on it. vis a vis, gnome
[03:05:49] <DeHackEd> unless something changes, your options are ship systemd, or don't ship gnome
[03:05:57] <jasonwc> Ah, true
[03:06:04] <cirdan> jasonwc: it's basically the same story as brexit, as trump, etc
[03:06:07] <bunder> mate still works
[03:06:19] <cirdan> get a few key people to swing the vote
[03:06:26] <jasonwc> People being fooled by ridiculous, absurd promises?
[03:06:28] <cirdan> gnome still works on bsd, iirc
[03:06:29] <DeHackEd> yeah when centos8 comes out I'm seriously considering making a non-systemd variation
[03:06:41] <cirdan> and os x
[03:07:04] <jasonwc> cirdan: It is utterly amazing to me that a large plurality of the UK still thinks Brexit is a good idea, and will benefit the UK.
[03:07:04] * CompanionCube mostly likes the init component of systemd
[03:07:19] <cirdan> jasonwc: same here w//trump
[03:07:21] <jasonwc> Every economic analysis indicates they'll be poorer
[03:07:29] <cirdan> but people are finally realize they are bent over
[03:07:29] <CompanionCube> jasonwc: said people are delusional
[03:07:34] <jasonwc> Haven't you heard? He's already built the wall!
[03:07:35] <CompanionCube> or have bullshit reasons
[03:07:36] <ptx0> #zfsonlinux-social
[03:07:48] *** nils_ <nils_!~nils_@pdpc/supporter/35for7/nils> has quit IRC (Ping timeout: 252 seconds)
[03:08:35] <cirdan> jasonwc: yeah well he said some serious shit today... and it will not go well in the end
[03:09:02] <bunder> if i knew c better i would port smf to linux
[03:09:25] <cirdan> Sacramento International Airport?
[03:09:35] <cirdan> or Sunset Music Festival
[03:09:55] <jasonwc> cirdan: Well, he *did* something of serious import today. However, his 50 minutes of stream-of-conscious drivel was not important.
[03:11:26] <CompanionCube> bunder: can't
[03:11:43] <CompanionCube> rather fundamental bits rely on solaris-specific functionality
[03:12:45] * ptx0 cough
[03:12:47] <ptx0> jasonwc
[03:12:48] <CompanionCube> if you knew C better a better option would be taking SystemXVI and building on that
[03:12:53] <ptx0> stahp
[03:13:05] <cirdan> ptx0 is having a stroke
[03:14:43] <jasonwc> #8419
[03:14:49] <jasonwc> Looks like it's actually coming :P
[03:15:46] <bunder> dead repo
[03:15:52] <CompanionCube> exactly
[03:16:05] <CompanionCube> why do you think i said take it and build on it?
[03:16:07] <cirdan> so zombify it
[03:16:47] <CompanionCube> (if i was the one doing it I'd also swap out SunRPC for something better)
[03:18:15] <jasonwc> There appear to be some issues outstanding re: autotrim but is the manual TRIM feature fine?
[03:20:34] *** nils_ <nils_!~nils_@pdpc/supporter/35for7/nils> has joined #zfsonlinux
[03:22:10] <cirdan> jasonwc: non-reproducible when running autotrim or manual TRIM independently
[03:23:57] <cirdan> i dont understand
[03:25:57] <jasonwc> cirdan: So, it's only a problem when both are used?
[03:27:11] <bunder> nope, i removed broadcastcellreceiver after test day
[03:27:21] <bunder> almost threw my phone at the wall when it went off
[03:29:02] <bunder> if ww3 breaks out, i'm sure i'll hear my neighbours screaming
[03:31:05] <ptx0> ^ srsly
[03:31:08] <ptx0> a solaris issue?
[03:31:36] <bunder> if it were v28 i'd say okay
[03:36:55] <RoyK> how far is raid vdev expansion from entering linux now?
[03:39:21] <bunder> i'm not seeing a pr
[03:39:55] <jasonwc> RoyK: It's still in development. It's being worked on by Matt Ahrens. I believe he was supposed to provide an update in Oct 2018 but I haven't heard anything.
[03:40:02] <jasonwc> It certainly won't make it into 0.8
[03:40:24] <jasonwc> Beyond that, I don't think anyone knows.
[03:40:33] <DHE> wtf... how did that solaris ticket not get stomped immediately?
[03:40:57] <jasonwc> RoyK: Given that it's probably the most demanded feature, per Matt Ahrens, I'm sure there will be an update when there is news.
[03:41:13] <jasonwc> RoyK: There are monthly developer conference calls with updates on OpenZFS that are public.
[03:41:42] <bunder> AllanJude: any news on raidz expansion on fbsd?
[03:42:39] <jasonwc> bunder: I asked a few days ago. He just said that Matt was really busy.
[03:42:58] <bunder> ah okay
[03:43:23] <bunder> i mean ix was sponsoring it, but google isn't turning up much other than reddit threads
[03:43:24] <ptx0> matt's on vacation
[03:44:34] <CompanionCube> ptx0: inb4 same vacation spot as brady
[03:45:21] <bunder> actually its funny, i saw brady on github the other day
[03:45:33] <ptx0> were you there buying a sandwich or something
[03:45:36] <jasonwc> bunder: I was searching for updates but found nothing recent. Matt has given several talks about the design. I think he has a working demo that does the expansion in a single TXG
[03:46:12] <jasonwc> *working code
[03:46:17] <bunder> maybe it got delayed with the changes to removal/remap
[03:46:48] <DHE> conceptually it's not that hard. I think the tricky part is reshaping the existing data in a crash-safe way, and you have all this new space available to use. :)
[03:48:03] <bunder> i forget, does it let you just add disks, or can you change a z2 into a z3 with it?
[03:48:07] <DHE> no
[03:48:11] <DHE> add disks only
[03:48:21] <bunder> needs improvement :P
[03:48:36] <DHE> it's already an improvement over what we have now. quit yer whining
[03:48:39] <DHE> :)
[03:51:09] <jasonwc> As Matt said in his talk, you still have to do *some* planning
[03:51:33] <ptx0> hey DHE can you look at that 3814 and 8142
[03:51:34] <jasonwc> Being able to expand a raidz vdev by adding individual disks rather than adding new top-level vdevs will make ZFS a lot more attracative for home storage usage
[03:51:37] <ptx0> see if it resolves your concerns
[03:52:47] <cirdan> jasonwc: yeah it can be rough to recreate a larger pool to add a drive
[03:52:54] <bunder> i'm already planning to use all 12 drive bays in my threadripper
[03:53:26] <DeHackEd> ptx0: way ahead of you
[03:53:47] <ptx0> DeHackEd: can you open a new issue for that
[03:53:53] <DeHackEd> 3814 should be good to be closed
[03:53:56] <DeHackEd> yeah that's probably best
[03:54:00] <DeHackEd> let me check there's no such thing already
[03:54:00] <ptx0> thanks
[03:54:05] <ptx0> yeah good idea, lole
[03:54:16] * ptx0 will just have to close it in 4 days when he finally makes it that far
[03:54:33] <DeHackEd> going in chronological/issue# order?
[03:54:34] <CompanionCube> are you doing a full stale issue sweep?
[03:57:22] <RoyK> jasonwc: thanks
[03:57:50] <jasonwc> wow, you've closed a bunch today
[03:59:35] <prometheanfire> heh, going through all the old bugs
[04:01:31] <cirdan> bunder: yeah but for reasons I have multiple pools
[04:01:54] <cirdan> mostly cause I can't afford to replace 16 drives at a time
[04:04:00] <ptx0> prometheanfire: fwiw i find noauto to be more convenient
[04:04:08] <ptx0> also yes i am going through all of them
[04:04:24] <ptx0> i closed about 50 issues and categorised about 100
[04:04:29] <cirdan> noauto and canmount are handy
[04:05:10] <DeHackEd> for some reason previewing in github doesn't work anymore so I hope this is formatted okay
[04:05:23] <DeHackEd> woah that went very wrong.
[04:05:35] <DeHackEd> oh fuck off, I can't even edit it...
[04:05:54] <cirdan> doom
[04:06:32] <ptx0> fixed
[04:06:45] <DeHackEd> thanks
[04:06:50] <jasonwc> Preview no longer works?
[04:06:55] <prometheanfire> ptx0: eh, I prefer the certianty of canmount
[04:07:12] <ptx0> prometheanfire: it is canmount=noauto
[04:07:25] <ptx0> prometheanfire: zfs mount -a won't do it but zfs mount <foo> will
[04:07:35] <DeHackEd> eg: selecting the "author" filter on the main issue/PR list, or closing those little popups that show up all over the place because github thinks we're retards
[04:07:42] <ptx0> i do it so i can manually access backups
[04:07:56] <ptx0> works here
[04:08:39] <prometheanfire> if I need access I'll change the property
[04:08:59] <ptx0> :P
[04:09:08] <ptx0> my gd script kept overwriting it when i did
[04:09:54] <ptx0> zfs in 2014 was an interesting era
[04:10:17] * ptx0 remembers how scary it was
[04:11:33] * DeHackEd had 8 production servers running ZFS in 2014
[04:11:44] <CompanionCube> what was the scariest part?
[04:11:51] <DeHackEd> no ABD
[04:12:02] <DeHackEd> or maybe it was just in the early initial PR states...
[04:12:04] <CompanionCube> but that's not unique to 2014
[04:12:30] <CompanionCube> wasn't it only merged in 2017 or so?
[04:12:40] <ptx0> zvol really sucked, memory blew
[04:12:49] <DeHackEd> ABD made the 0.7.0 release..
[04:12:52] <ptx0> xattr bugs
[04:13:07] <PMT> DeHackEd: here i was hoping you might have been offering a PR with it implemented
[04:14:34] <CompanionCube> DeHackEd: ah, ABD made an rc in january 2017 which is likely why i remember that
[04:16:23] <jasonwc> DeHackEd: oh, we had this conversation before. Those aspects of Github still work for me. Must be a browser issue. I'm on the latest stable Chrome release.
[04:16:59] <DeHackEd> jasonwc: firefox 52 (last ESR that didn't suck)
[04:17:11] <jasonwc> yup, that's why it doesn't work, heh
[04:17:55] <CompanionCube> >implying the W3C's the one doing the fucking
[04:18:04] * CompanionCube is happy with current firefox
[04:18:42] <DeHackEd> the latest ESR (which is what my distro ships) has said "fuck java (sorry, I still need it) and fuck all your existing extensions". so I'm not upgrading.
[04:21:08] <ptx0> i use firefox 69
[04:21:18] <bunder> but 52 has vulnerabilities
[04:21:54] <DeHackEd> it's 52.8 (?) which has the security fixes equivalent to just shy of the next major ESR release.
[04:26:05] *** Markow <Markowfirstname.lastname@example.org> has quit IRC (Quit: Leaving)
[04:29:17] <bunder> 52.8.1 has 188 and 52.9.0 has 36
[04:36:40] <DeHackEd> naturally...
[04:36:52] <DeHackEd> is there an actual list somewhere?
[04:55:32] *** elxa <elxa!~elxa@2a01:5c0:e09b:bee1:e0a7:af10:af35:bf6e> has quit IRC (Ping timeout: 258 seconds)
[04:56:56] <bunder> i was using one of those cve pages, one sec
[05:03:01] <bunder> Manually dragging and dropping an Outlook email message into the browser will trigger a page navigation when the message's mail columns are incorrectly interpreted as a URL
[05:03:10] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 250 seconds)
[05:03:15] <bunder> i'm not sure how that's a vulnerability, but okay
[05:04:03] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #zfsonlinux
[05:08:09] <PMT> bunder: I mean, the risk is low, but the possible impact may be higher
[05:08:17] *** elxa <elxa!~elxa@2a01:5c0:e080:b281:ff07:d593:8a4b:e5b4> has joined #zfsonlinux
[05:09:29] <bunder> also, shouldn't that be a windows OLE bug not firefox
[05:10:13] <bunder> if i drag a pdf into firefox it opens acrobat
[05:12:08] <bunder> wily? i don't even recall that release
[05:12:21] <PMT> bunder: 1704 i think
[05:12:32] <PMT> oh not even, 1510
[05:14:01] <bunder> oh maybe that's why, if its a .10
[05:21:20] <bunder> oh nice new proton with faudio
[05:21:35] <jasonwc> Ubuntu Wily (15.10) wasn't a LTS release. Probably why you forgot about it.
[05:23:02] <bunder> yeah that too
[05:23:11] <ptx0> LOL
[05:23:18] <ptx0> god one alek
[05:23:21] <ptx0> good*
[05:32:00] <bunder> holes
[05:36:35] <bunder> speaking of nexenta, how come their repo is so old
[05:36:58] <bunder> hasn't been touched in 3 years
[05:37:21] <AllanJude> who wants to try my patch to improve ZFS send size estimation?
[05:37:43] <AllanJude> for my test case, it improves the accuracy from 23% under actual, to 7% under actual
[05:38:33] <bunder> i would if i was home right now
[05:39:17] <AllanJude> I feel it is a bit early to create a pull request for it
[05:39:23] <bunder> on visual inspection it looks fine
[05:39:34] <AllanJude> i have a more invasive version
[05:39:52] <AllanJude> that actually counts the objects, based on the way bookmark calculations are done
[05:40:01] <AllanJude> and it could also take -e into consideration
[05:40:18] <AllanJude> as the size estimate is wrong by 512 bytes * # of embedded bps
[05:40:22] <AllanJude> when you use -e
[05:40:30] <AllanJude> but, I imagine that will be much slower
[05:40:34] <AllanJude> since it has to talk all of the bps
[05:40:44] <AllanJude> ptx0: I have considered that
[05:41:08] <AllanJude> but this seems to help a lot
[05:41:12] <ptx0> looks like i've closed 125 issues today
[05:41:14] <AllanJude> although I am unclear why it is still off by 7%
[05:41:20] <bunder> i see no problem with a full walk, i think i would prefer it rather than fudging numbers
[05:41:22] <AllanJude> ptx0: ahh, is kpande you?
[05:41:25] <ptx0> yep
[05:41:37] <AllanJude> couldn't put a real name (or face) to the github username
[05:41:44] <ptx0> ah
[05:41:54] <bunder> doesn't help that he has like six github accounts
[05:42:08] <AllanJude> yeah, the kpande one is basically only zol
[05:42:38] <ptx0> it used to be other things but i was sued :P
[05:43:25] <ptx0> now i work on projects mostly anonymously.
[05:45:06] <AllanJude> one of the co-founders of FreeBSD had a similar situation
[05:45:26] <AllanJude> worked as a lumberjack for quite a few years, waiting for non-competes etc from the settlements to wear off
[05:48:46] <ptx0> met him in Chemainus, BC
[05:48:54] <ptx0> just a coincidence at a laundromat
[05:48:59] <ptx0> that was a fun day.
[05:49:29] <ptx0> maybe the same person anyway, can't imagine too many people have the same story of being one of the founders etc
[05:50:18] <AllanJude> Rod Grimes
[05:50:38] <AllanJude> he finally re-joined the project about 3 years ago
[05:51:14] <ptx0> oh, oops, the person i knew was from openbsd
[05:51:16] <ptx0> :P
[05:51:38] <ptx0> so open source hoodlums get sued a lot eh
[05:52:37] <bunder> that guy who threatened to sue me still hasn't pushed his const patch yet
[05:53:07] <ptx0> just wait til i get to his issue and close it for inactivity
[05:53:21] * ptx0 jk
[05:53:27] <ptx0> maybe ;)
[05:53:50] <bunder> not sure he has much of a leg to stand on if the pr is closed and never got merged
[06:05:25] <bunder> could probably close that one
[06:07:21] <AllanJude> snapshot with a hold
[06:07:26] <AllanJude> is how I prevent such foot shooting
[06:08:36] <AllanJude> also, zfs's entire CLI needs an overhaul in relation to -f, it is overloaded it too many places, and there should be flags for each 'case'. Like I want to 'zpool import --ignore-hostid', rather than -f, since -f means 'ignore these 6 different causes for failure'
[06:11:34] <bunder> holds are pretty new
[06:12:01] <PMT> it's true, it could use a significant rework.
[06:23:54] *** jasonwc <email@example.com> has quit IRC ()
[06:24:04] <bunder> oh crap i didn't even notice that the whole time
[06:25:57] <bunder> trying to download a 7.4 rpm from the 7.6 directory
[06:36:32] *** c3-Win <c3-Win!~c3r1c3-Wi@ip72-211-81-173.no.no.cox.net> has joined #zfsonlinux
[06:36:47] *** veegee_ <firstname.lastname@example.org> has joined #zfsonlinux
[06:38:29] *** DzAirmaX_ <DzAirmaX_!~DzAirmaX@unaffiliated/dzairmax> has joined #zfsonlinux
[06:38:32] *** BtbN_ <BtbN_!btbn@ffmpeg/developer/btbn> has joined #zfsonlinux
[06:40:11] *** ChibaPet <ChibaPet!~mason@redhat/mason> has joined #zfsonlinux
[06:40:56] *** malevolent_ <email@example.com> has joined #zfsonlinux
[06:41:18] *** veegee <firstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** DzAirmaX <DzAirmaX!~DzAirmaX@unaffiliated/dzairmax> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** lundman <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** mason <mason!~mason@redhat/mason> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** xlued <firstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** duairc <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** mmlb <firstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** Llewelyn <Llewelynemail@example.com> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** nicoulaj <firstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** migy <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[06:41:18] *** BtbN <BtbN!btbn@ffmpeg/developer/btbn> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** c3r1c3-Win <c3r1c3-Win!~c3r1c3-Wi@ip72-211-81-173.no.no.cox.net> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** Freeaqingme <Freeaqingmefirstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** FireSnake <FireSnake!firesnake@gateway/shell/xshellz/x-nemggintglraiurq> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** malevolent <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** javi404 <javi404!~quassel@unaffiliated/javi404> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** allquixotic <allquixotic!~quassel@pdpc/supporter/bronze/allquixotic> has quit IRC (Ping timeout: 246 seconds)
[06:41:19] *** buu <firstname.lastname@example.org> has quit IRC (Remote host closed the connection)
[06:41:19] *** BtbN_ is now known as BtbN
[06:41:19] *** buu_ <email@example.com> has joined #zfsonlinux
[06:41:19] *** migy_ <firstname.lastname@example.org> has joined #zfsonlinux
[06:41:43] *** vertigo_ <vertigo_!~chris@unaffiliated/anunnaki> has joined #zfsonlinux
[06:42:36] *** xlued <email@example.com> has joined #zfsonlinux
[06:43:21] *** SadMan <SadManfirstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[06:43:23] *** vertigo <vertigo!~chris@unaffiliated/anunnaki> has quit IRC (Remote host closed the connection)
[06:43:57] *** Llewelyn <Llewelynemail@example.com> has joined #zfsonlinux
[06:49:46] *** c3-Win is now known as c3r1c3-Win
[06:50:46] *** mmlb <firstname.lastname@example.org> has joined #zfsonlinux
[06:51:13] *** Freeaqingme <Freeaqingmeemail@example.com> has joined #zfsonlinux
[06:58:10] <bunder> oh boy
[07:04:22] <bunder> pcd: you might want to see this :)
[07:36:07] <Shinigami-Sama> I think you mean ptx0
[07:36:34] *** oblikoamorrale <oblikoamorrale!~ami@pdpc/supporter/active/oblikoamorale> has joined #zfsonlinux
[07:36:54] <bunder> no
[07:37:04] <bunder> pcd wants to remove send dedup
[07:37:18] <bunder> #7887
[07:37:32] <Shinigami-Sama> everyone wants to remove dedup
[07:38:47] *** oblikoamorale <oblikoamorale!~ami@pdpc/supporter/active/oblikoamorale> has quit IRC (Ping timeout: 240 seconds)
[07:38:57] *** oblikoamorrale is now known as oblikoamorale
[07:39:15] <bunder> because it sucks :P
[07:47:19] <CompanionCube> ptx0: inb4 get github bot to close stale issues
[07:56:56] <bunder> lol twice in a row too
[08:01:19] <AllanJude> Shinigami-Sama: there is dedup send, which is unrelated to normal dedup
[08:07:01] *** AllanJude <AllanJude!ajude@freebsd/developer/AllanJude> has quit IRC (Remote host closed the connection)
[08:15:03] *** IonTau <IonTau!~IonTau@203-206-42-171.dyn.iinet.net.au> has quit IRC (Remote host closed the connection)
[08:36:48] *** pR0Ps <pR0Ps!~pR0Ps@126.96.36.199> has quit IRC (Ping timeout: 250 seconds)
[08:40:04] *** pR0Ps <pR0Ps!~pR0Ps@104-222-122-23.cpe.teksavvy.com> has joined #zfsonlinux
[08:46:10] <ptx0> jeez
[08:46:13] <ptx0> send -R is fuckin broken.
[08:50:13] <bunder> i don't think i've ever used it
[08:52:39] <bunder> i wonder what's in that 12.6kb
[08:54:12] <bunder> if there's nothing to send it should be zero
[09:00:51] *** cheet <firstname.lastname@example.org> has quit IRC (Quit: ZNC 1.8.x-nightly-20190128-91af796c - https://znc.in)
[09:08:26] <bunder> its like its ignoring the first snapshot and sending everything from beginning to snap2
[09:08:34] <ptx0> yes it is
[09:15:37] <bunder> i wonder if that's what happened to your enc pool
[09:16:46] <bunder> i could try receiving the snap but i'd want to be home so i can reboot my laptop if it crashes
[09:41:15] *** catalase <catalase!Elite21895@gateway/shell/elitebnc/x-xbmtveemaawuoogv> has quit IRC (Ping timeout: 252 seconds)
[10:44:36] <bunder> osnap
[10:50:57] *** LeoTh3o <LeoTh3oemail@example.com> has quit IRC (Quit: Leaving)
[10:51:09] *** LeoTh3o <LeoTh3ofirstname.lastname@example.org> has joined #zfsonlinux
[10:53:07] *** MasterPiece <MasterPiece!~masterpie@unaffiliated/masterpiece> has joined #zfsonlinux
[11:01:56] *** bz2 <bz2!~z@unaffiliated/zst> has joined #zfsonlinux
[11:04:39] *** zst <zst!~z@unaffiliated/zst> has quit IRC (Ping timeout: 268 seconds)
[11:04:42] *** bz2 is now known as zst
[11:09:11] *** SadMan <SadManemail@example.com> has joined #zfsonlinux
[11:14:09] <bunder> hey save some for the rest of us lul
[11:22:45] <ptx0> heh
[11:30:39] <ptx0> down to 842 bunder
[11:30:50] <bunder> lol
[11:42:04] <ptx0> jesus
[11:42:07] <ptx0> i've only gone through 8 pages
[11:42:21] <ptx0> there's 34
[11:42:49] <hyper_ch> closing bugs?
[11:43:04] <ptx0> yeah and filing them
[11:43:19] <ptx0> because behlendorf keeps removing tags and then github just leaves a ton of issues without one
[11:43:22] <ptx0> lol
[11:43:48] <hyper_ch> finally fixed my nixos/systemd/zfs problem :)
[11:43:54] <ptx0> went from ~995 issues to 840-something
[11:44:01] <ptx0> 832 now
[11:44:21] <hyper_ch> still a lot of work left :)
[11:44:26] <ptx0> what was the magic hint
[11:44:48] <ptx0> "This man got his NixOS installation to work. You won't BELIEVE how!!!"
[11:45:08] <ptx0> what would the dailymail.co.uk headline look like
[11:45:41] <hyper_ch> well, I use nixos. Nixos uses a declarative config file to actually install all the stuff. ZFS requires a hostid which is in the "normal" networking section. However that server acts as host for some qemu VMs. with the systemd.network I did create a bridge and that worked fine up to systemd 237. However with systemd 239 suddenly the host couldn't ping anything anymore.
[11:46:03] <hyper_ch> for some reason (also in he old version) two default gateways entries were added... it worked on 237 but not 239
[11:47:40] <hyper_ch> also, I want to boot and unlock server remotely. What I had to do is (a) add boot.kernelParams = [ "ip=dhcp" ]; then remove the useDHCP="yes"; part from the normal networking section, add nameserver entries to the systemd.network section
[11:48:01] <hyper_ch> no only 1 default gateway, I can still unlock server remotely upon reboot and netowrking all works :)
[11:49:10] <CompanionCube> related to nixos: today i read about fedora silverblue. I think not knowing may have been better.
[11:49:51] <hyper_ch> what's silverblue?
[11:50:11] *** Markow <Markowfirstname.lastname@example.org> has joined #zfsonlinux
[11:52:08] <hyper_ch> no there's the other office server that I also need to upgrade :)
[11:52:17] <hyper_ch> CompanionCube: fail to see how that's related to nixos
[11:53:17] <CompanionCube> hyper_ch: the whole thing sounds like a worse implementation of nixos/guixsd
[11:54:28] <CompanionCube> hell, you might even say windows arguably has a better method :p
[11:55:06] <ptx0> windows deployment magic?
[11:55:08] <hyper_ch> CompanionCube: I just read about "snap/py" the other day.... didn't canoncial wanted to enable atomic ugprades with that?
[11:55:15] <ptx0> SDM thing
[11:55:33] <hyper_ch> I really like that Windows now comes with WSL
[11:55:36] <CompanionCube> isn't that for enterprise
[11:55:37] <hyper_ch> that makes so many things easier
[11:55:55] <ptx0> wish i hadn't reproduced that issue with dbu_evict on my workstation earlier
[11:56:00] <ptx0> cpu's been spinning for a few hours
[11:56:02] <ptx0> lol
[11:56:11] <CompanionCube> hyper_ch: i believe snap in the same category, yes
[11:56:13] <ptx0> Seems Fine Though (TM)
[11:56:25] <CompanionCube> ptx0: it's a threadripper
[11:56:35] <ptx0> yeah it's only at 46C
[11:56:41] <ptx0> like i said, seems fine
[11:56:43] <CompanionCube> you have basically infinite spare cores
[11:56:49] <ptx0> kswapd is poopin along though
[11:56:54] <ptx0> i don't even have swap
[11:57:15] <hyper_ch> infinite spare cores?
[11:57:27] <ptx0> oh wait
[11:57:30] <ptx0> the system isn't stuck
[11:57:35] <ptx0> conky just died earlier
[11:57:41] <bunder> funny
[11:57:53] <bunder> first result for dbu_evict is your 4462
[11:57:57] <ptx0> ah wait it's stuck
[11:58:08] <ptx0> oh
[11:58:09] <ptx0> nope
[11:58:09] <hyper_ch> btw, are the AMD Threadrippers really so good?I just stuck to Intel the last decade out of habit... especially when they first introduced aes-ni
[11:58:30] <bunder> don't get the wx, just the x
[11:59:05] <ptx0> i'm on a 1900x and it is spectacular
[11:59:17] <ptx0> kids who love intel CPUs tend to play games, i tend to do work
[11:59:28] <bunder> if you want 16c32t and don't want to pay $1700 for the chip, tr is the way to go
[11:59:53] <ptx0> there's people like jasonwc who will spend 2x on half the functionality because it'll get him a few higher peak fps in a game or two
[12:00:03] <hyper_ch> well, whenwe have next server upgrades I'll probably switch them... currently 4c/8t i7
[12:00:14] <ptx0> i7 doesn't even have ECC...
[12:00:26] <hyper_ch> I'm still ECC-free :(
[12:00:30] <hyper_ch> thats the next thing
[12:02:00] <bunder> ecc is expensive, 128gb quad channel ddr4 already set me back a grand
[12:02:21] <ptx0> why 128gb tho
[12:03:01] <ptx0> that is excessive :P
[12:03:30] * ptx0 just went from 16 to 32G in the local backup server and it feels like overkill
[12:03:38] <ptx0> not running dozens of VMs though
[12:04:45] <bunder> i plan on running like 4 or 5 vm's at a time, plus arc for nfs and the host
[12:06:03] *** metallicus <email@example.com> has joined #zfsonlinux
[12:06:40] *** metallicus <firstname.lastname@example.org> has quit IRC (Client Quit)
[12:08:49] <hyper_ch> ecc doesn't seem much more expensive the lsat time I looked
[12:10:41] <bunder> to be fair, i didn't feel like fighting with it, because afaik you can't run ecc at the speeds you would with standard memory
[12:11:02] <bunder> and supposedly you can't run quad channel at those speeds either, but why would 2666 quad channel be on the qvl /shrug
[12:11:05] <ptx0> well, standard memory at xmp speeds is prone to errors too
[12:11:18] <hyper_ch> ecc is slower than standard memory?
[12:11:25] <ptx0> you can run QC at 2666MHz but it'll be overclocking the CPU
[12:11:32] <bunder> no its something to do with the memory controller
[12:11:49] <Lalufu> I'm running quad channel at 3200, only 32GB, though
[12:12:00] <bunder> 8 sticks?
[12:12:03] <Lalufu> 4
[12:12:13] <bunder> ah
[12:17:08] *** Markow <Markowemail@example.com> has quit IRC (Ping timeout: 245 seconds)
[12:18:07] *** Markow <Markowfirstname.lastname@example.org> has joined #zfsonlinux
[12:25:24] <hyper_ch> what do you use 128GB ram for?
[12:26:07] <bunder> bunder | i plan on running like 4 or 5 vm's at a time, plus arc for nfs and the host
[12:30:46] <hyper_ch> those are ram hungry vms then
[12:31:48] <DeHackEd> you give VMs what they need
[12:35:56] *** notdaniel <notdaniel!~dkh@2600:1700:9bd0:2470::33> has joined #zfsonlinux
[12:40:32] *** mquin <mquin!~mike@freenode/staff/mquin> has quit IRC (Quit: So Much For Subtlety)
[12:41:28] <bunder> clamav alone says it needs at least 650mb on my current hardware
[12:42:59] <bunder> amavis is another 3-400
[12:44:52] <bunder> apache is 250
[12:45:55] <hyper_ch> so, other office server also upgrade :)
[12:46:31] <hyper_ch> notebook battery almost dead... it's being past noon already... so good time to buy groceries, have lunch and call it a weekend :)
[12:46:40] <bunder> lol
[12:47:09] <hyper_ch> you disagree?
[12:48:00] *** LeoTh3o <LeoTh3oemail@example.com> has quit IRC (Quit: Leaving)
[12:49:37] *** LeoTh3o <LeoTh3ofirstname.lastname@example.org> has joined #zfsonlinux
[12:50:59] <bunder> no i was laughing at the battery being dead so early into the day
[12:51:20] <hyper_ch> it's 12:51 :)
[12:51:21] <bunder> its like my cellphone, take it off the charger at like 6am and its dead by noon
[12:51:25] <hyper_ch> how long does your notebook battery last?
[12:51:49] <bunder> depends on what i'm doing
[12:51:59] <bunder> but i usually leave it plugged in
[12:52:05] <hyper_ch> mine lasts around 4h
[12:52:09] <bunder> (i know it defeats the purpose)
[12:52:31] <notdaniel> my iphone x is the first phone i recall for years surviving beyond a day
[12:52:41] <hyper_ch> well, off now :)
[12:53:10] <bunder> cheers
[12:54:19] <bunder> notdaniel: i would say that's good, but apple has a history of making their phones intentionally slow
[12:54:56] <notdaniel> well theyve done that recently because the alternative was the battery not being able to survive
[12:55:03] <notdaniel> thus the stories of phone shutdowns at 20%
[12:55:14] <notdaniel> the slower speed hack was the tradeoff
[12:55:27] <notdaniel> if you have a newer phone this is not in any way a problem
[12:55:39] <notdaniel> best performing phone ive ever had
[12:55:50] <bunder> and you can't change the battery on an apple
[12:55:53] <notdaniel> if i keep it for ten years and expect it to work the same with the new os, maybe not
[12:55:59] <bunder> well, kindof sortof
[12:56:23] <notdaniel> barking up the wrong tree
[12:56:25] <bunder> i forget if they still replace the phone like they do with screens
[12:56:37] <notdaniel> i know the arguments and i do not care and i continue to buy iphones
[12:57:01] <bunder> eh to be fair androids been sealing the batteries in too, which is why i use an s5
[12:57:15] <notdaniel> because at the end of the day it gives me by far the least grief than anything else i use
[13:02:03] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has joined #zfsonlinux
[13:02:06] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has quit IRC (Max SendQ exceeded)
[13:05:24] *** MasterPiece <MasterPiece!~masterpie@unaffiliated/masterpiece> has quit IRC (Quit: Leaving)
[13:20:55] *** mquin <mquin!~mike@freenode/staff/mquin> has joined #zfsonlinux
[13:23:20] <bunder> i wanted to get the ubuntu phone but i dont think they are making the hardware anymore
[13:27:27] <lblume> Nor the software.
[13:29:17] <notdaniel> not really the ideal scenario for your most essential communication device
[13:32:13] *** b <b!coffee@gateway/vpn/privateinternetaccess/b> has joined #zfsonlinux
[13:33:50] <bunder> what do i need other than phone/sms and email
[13:33:56] <bunder> the rest is superfluous
[13:34:30] <bunder> i guess gps is nice but that's about it
[13:35:47] <lblume> Security updates.
[13:36:03] <bunder> its linux
[13:37:13] <lblume> ... yes? So? Main part of my job is keeping track of Linux security updates.
[13:37:22] <bunder> oh, i guess ubu isn't supporting it anymore but ubports is
[13:38:14] <notdaniel> the dream is superfluity along with stability
[13:38:40] <notdaniel> whther it's my phone or my life
[13:38:44] <notdaniel> also i have over 20k unread emails
[13:39:22] <lblume> Only? Lucky you :)
[13:47:15] <bunder> 49, but most of those are my */6 mailq checks
[13:56:59] <cirdan> bunder: you can change the battery in mac/iphones but the mac is a little hard
[13:57:28] <cirdan> apple sill do a phone exchange if anything at all goes wrong, they dont wanna deal with a battery fire so they'll send it out and give you a refurb
[13:57:39] <bunder> i said kindof sortof :P
[13:59:58] <bunder> i can walk into any samsung repair shop and get any parts i need for my s5
[13:59:58] *** notdaniel <notdaniel!~dkh@2600:1700:9bd0:2470::33> has quit IRC (Read error: Connection reset by peer)
[14:11:14] <cirdan> for now
[14:13:56] <cirdan> wonder if i can get a new battery for my nokia 9300i
[14:17:03] <bunder> aliexpress/ebay
[14:17:09] <bunder> sorry :P
[14:23:17] <lblume> I had an Android with a replaceable battery. When it failed, after 4 years, it was not possible to buy a genuine new one anymore.
[14:26:58] <bunder> yeah i think i lucked out with samsung, doubt i could get moto parts anymore either
[14:35:16] *** akaizen <email@example.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[14:55:58] *** Hypfer <Hypfer!~Hypfer@unaffiliated/hypfer> has joined #zfsonlinux
[14:56:59] *** rich0 <rich0!~quassel@gentoo/developer/rich0> has quit IRC (Quit: rich0)
[14:59:34] *** rich0 <rich0!~quassel@gentoo/developer/rich0> has joined #zfsonlinux
[15:07:49] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[15:08:58] *** fs2 <email@example.com> has joined #zfsonlinux
[15:23:04] *** Markow <Markowfirstname.lastname@example.org> has quit IRC (Quit: Leaving)
[15:26:44] *** sauravg_ <email@example.com> has quit IRC (Ping timeout: 250 seconds)
[15:34:33] *** sauravg <firstname.lastname@example.org> has joined #zfsonlinux
[15:37:59] *** mmlb <email@example.com> has quit IRC (Ping timeout: 255 seconds)
[15:38:51] *** mmlb <firstname.lastname@example.org> has joined #zfsonlinux
[15:54:22] <bol> Fairphone2 + LineageOS will be my next device
[15:54:55] <bol> Easy to repair if it breaks, and upgradable hardware modules
[16:01:00] *** tomoyat1 <email@example.com> has quit IRC (Quit: ZNC 1.6.5 - http://znc.in)
[16:01:32] *** tomoyat1 <firstname.lastname@example.org> has joined #zfsonlinux
[16:03:34] *** fs2 <email@example.com> has quit IRC (Quit: Ping timeout (120 seconds))
[16:04:28] <ChibaPet> bol: Ah, I've been looking for a Lineage phone. I'll look at that.
[16:04:33] <ChibaPet> hm
[16:04:34] *** ChibaPet is now known as mason
[16:04:45] <mason> Freenode must have gone away overnight.
[16:06:45] *** fs2 <firstname.lastname@example.org> has joined #zfsonlinux
[16:11:24] *** hsp <hsp!~hsp@unaffiliated/hsp> has quit IRC (Quit: WeeChat 2.3)
[16:12:35] <cirdan> ?
[16:12:42] <cirdan> nope
[16:14:33] *** fs2 <email@example.com> has quit IRC (Quit: Ping timeout (120 seconds))
[16:15:28] <cirdan> PMT: so... i ran a long smart test. Extended offline Completed without error. Current_Pending_Sector 8
[16:15:31] <cirdan> ¯\_ツ_/¯
[16:15:35] *** fs2 <firstname.lastname@example.org> has joined #zfsonlinux
[16:16:22] <DeHackEd> ... I can't open a pull request...
[16:17:06] <cirdan> DeHackEd: disable ublock and see if it works
[16:17:21] *** hsp <hsp!~hsp@unaffiliated/hsp> has joined #zfsonlinux
[16:17:36] <DeHackEd> I'm not running ublock
[16:17:40] <cirdan> one day 2 months ago ublock blocked * on github
[16:17:42] <cirdan> no adblock at all?
[16:17:48] <DeHackEd> nope, just scriptsafe
[16:17:52] <DeHackEd> and github is allowed
[16:18:45] *** mmlb <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[16:23:10] <cirdan> try a diff browser?
[16:24:33] <DeHackEd> uhh, no
[16:26:12] <cirdan> same brwoser local different account
[16:27:34] * cirdan runs badblocks
[16:29:52] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[16:30:23] <DeHackEd> nope, can't upgrade
[16:32:49] *** fs2 <email@example.com> has joined #zfsonlinux
[16:58:14] * DeHackEd installs a fresh gentoo environment to build chromium in
[16:59:56] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[17:02:21] *** fs2 <email@example.com> has joined #zfsonlinux
[17:02:46] *** zfs sets mode: +b *!*@pwnhofer.at$#zfsonlinux-quarantine
[17:03:58] *** mmlb <firstname.lastname@example.org> has joined #zfsonlinux
[17:04:40] *** malevolent_ <email@example.com> has quit IRC (Ping timeout: 250 seconds)
[17:04:49] *** malevolent <firstname.lastname@example.org> has joined #zfsonlinux
[17:12:43] *** catalase <catalase!Elite21895@gateway/shell/elitebnc/x-cnpiaywdigfkedab> has joined #zfsonlinux
[17:20:21] *** AllanJude <AllanJude!ajude@freebsd/developer/AllanJude> has joined #zfsonlinux
[17:24:44] <storrgie> does one need to specify ashift when adding a cache device to the pool?
[17:27:15] <AllanJude> storrgie: if you want it to have that ashift
[17:28:38] <storrgie> I've got two Intel `SSDPEDMX400G4` and I was planning to add them to the pool as a mirrored log device (not cache, miss-spoke in earlier post), I think that I should use ashift=12 with hese
[17:30:44] <DeHackEd> storrgie: same as any other disk. specify it if autodetection isn't working right
[17:31:06] <storrgie> alright, just did it, I was just worried that with log devices ashift wouldn't be accepted
[17:31:18] <DeHackEd> error: you said "cache" earlier
[17:31:43] <AllanJude> storrgie: every top level vdev will accept ashift
[17:31:51] <AllanJude> you just can't mix ashifts inside a top level vdev
[17:32:22] <storrgie> and, am I correct in thinking that I should be adding a log to this pool if my objective is faster write speeds? It's a mirrored pool (4x2 HGST_HDN726060ALE610)
[17:32:26] <DeHackEd> ashift is a vdev property, yeah... you can mix disks with different sector sizes, at your own risk
[17:32:40] <DeHackEd> faster SYNCHRONOUS write speeds
[17:32:49] <storrgie> I'm thinking I don't need faster read speeds, there are plenty of IOPS in a four drive mirror for what folks are doing on there (running jupyter notebooks
[17:32:51] <DeHackEd> async apps like rsync don't give a shit about log devices
[17:42:20] *** gienah_ <gienah_!~mwright@gentoo/developer/gienah> has joined #zfsonlinux
[17:45:28] *** gienah <gienah!~mwright@gentoo/developer/gienah> has quit IRC (Ping timeout: 245 seconds)
[17:47:35] <AllanJude> yeah, only writes where the app asks to wait until the data is safe on disk, instead of just buffered in RAM (databases, hypervisors, etc) would benefit from a SLOG
[17:52:58] *** clete2 <email@example.com> has quit IRC (Ping timeout: 245 seconds)
[17:58:59] *** clete2 <firstname.lastname@example.org> has joined #zfsonlinux
[18:03:37] * DeHackEd builds a troll version of chromium... :)
[18:43:04] *** geaaru <email@example.com> has joined #zfsonlinux
[18:51:41] <DHE> There! I accomplished something!
[18:52:21] <DHE> I wanted to do something bigger, but this will do for now
[19:17:31] <geaaru> hi, is there a date for a new release 0.7.x with support to 4.20 kernel ? thanks in advance
[19:21:53] *** vaxsquid <firstname.lastname@example.org> has joined #zfsonlinux
[19:22:06] *** fs2 <email@example.com> has quit IRC (Quit: Ping timeout (120 seconds))
[19:23:16] <ptx0> geaaru: you can see the 'projects' tab on github
[19:25:05] <geaaru> +ptx0: ok, thank you
[19:47:15] <ptx0> classic
[19:51:13] <mason> Mm, good stuff.
[19:54:56] <ptx0> lol storing a checksum on disk
[19:55:47] <ptx0> that's so silly. what filesystem would ever do that?
[19:56:31] * ptx0 kinda wishes gregor would drop the issue and let zstd be implemented already
[20:13:30] <MilkmanDan> More than 6 years and still not to market.
[20:13:45] <AllanJude> ptx0: it was George Wilson's optimization in like 2014/2015 i think, where the L2ARC header stopped having its own checksum, and instead shared the on-disk checksum
[20:14:11] *** JMoVS <JMoVS!qjc8olfEKL@hamal.uberspace.de> has joined #zfsonlinux
[20:15:03] <AllanJude> funny that you should link about cpu cooling, have a server overheating
[20:15:22] <MilkmanDan> Is it the cpu?
[20:16:01] <ptx0> AllanJude: he's trying to be clever and bypass storing the checksum in memory
[20:16:32] <AllanJude> ptx0: who is?
[20:16:51] <ptx0> Gregor :P
[20:17:47] <ptx0> "self-checksum on-disk" as if that would not require being stored in memory at some point
[20:22:02] <ptx0> bunder: how many issues do you think we'll be left with when the cleanup is finished
[20:22:09] <ptx0> my guess is about 500
[20:22:53] <bunder> hard to say
[20:23:12] <ptx0> scan: scrub repaired 0B in 8 days 18:42:35 with 0 errors on Sun Feb 10 15:03:32 2019
[20:23:19] <ptx0> lol <3 resumable scrubs
[20:24:09] <bunder> MilkmanDan: they make a 17 and a 27mm
[20:24:51] <ptx0> bunder: so you were right about the background radiation eh
[20:25:10] <bunder> well, different person but its funny that it actually happens
[20:29:50] <PMT> ptx0: IMO compressed ARC shouldn't be mandatory, which probably means someone should make the L2ARC change to hold a CKSUM in there again.
[20:31:05] <ptx0> bunder: my coworker with corruption issues lives near there in russia
[20:31:08] <ptx0> now he's going to move :P
[20:31:16] <bunder> hah
[20:31:39] <ptx0> PMT: or make it optional
[20:31:48] <ptx0> i.e. "you want uncompressed ARC? you get inefficient l2arc"
[20:32:16] <ptx0> PMT: based on a survey of my 500+ customers though, compressed arc only helps
[20:32:17] <AllanJude> that is what you have today
[20:32:25] <AllanJude> you re-compress the data and send it to the L2ARC
[20:32:38] <AllanJude> the issue is mostly that with QAT or ZSTD that the recompression might not actually match
[20:33:04] <ptx0> AllanJude: yeah he just wants the checksum there always but i think why not only store it in the l2 hdr if we can't get away with NOT keeping it
[20:33:31] <AllanJude> well, if it is the same, there is no point storing the BP checksum and an L2ARC checksum
[20:33:31] <AllanJude> bu tyes
[20:33:41] <AllanJude> I did look at changing the L2ARC header union
[20:33:50] <AllanJude> to have a 'long' L2ARC header, that included the different checksum
[20:34:04] <ptx0> would that increase the header size for compressed arc too?
[20:34:07] <AllanJude> but the magic done with the ARC headers already is very fragile
[20:34:37] <AllanJude> ptx0: likely you'd use a flag in the arc header, to incidate if it is a large or small l2arc header, to avoid using more space when not needed
[20:34:46] <ptx0> yeah
[20:38:13] <bunder> DHE: don't we do zle on null blocks?
[20:39:07] <MilkmanDan> bunder: That's an ok cooler for low profile but it's not capable of >70W TDP and it doesn't actually use the air bearing tech, which is really disappointing.
[20:42:28] <ptx0> oh my god that review is lulz
[20:43:51] <AllanJude> bunder: no, if compression is anything but 'off', it actually compare every byte to 0, and if all of the bytes in a block are 0, we store it as a 'hole', and don't write any data, just the metadata
[20:44:21] <AllanJude> ZLE would be useful in cases where there were small amounts of non-zero, mixed in with lots of runs of zero bytes
[20:45:11] <MilkmanDan> I like that guy's videos. It's like hanging around with an awkward friend while he dorks out over some tech, and you just let him go because it's entertaining.
[20:46:03] * ptx0 shakes head
[20:46:06] <bunder> AllanJude: ah. by the way did you still want me to test that patch
[20:46:17] <AllanJude> yes please
[20:46:51] <AllanJude> more useful output would be:
[20:46:59] <AllanJude> zfs send -v ... | zstreamdump
[20:47:13] <ptx0> i've seen every single gamers nexus video, MilkmanDan
[20:47:19] <AllanJude> with combination of entire snapshots, and both -i and -I ranges
[20:47:40] <AllanJude> ideally with before/after
[20:47:46] <MilkmanDan> Oh, heh.
[20:48:52] <ptx0> the head shake was at the suggestion in 7896 to have a dual compressed/uncompressed ARC depending on hit rate
[20:49:06] * AllanJude has recorded over 600 podcast episodes, well over 1000 hours of video
[20:49:18] <AllanJude> ptx0: it seems they don't understand that there is already the cache of the uncompressed version
[20:49:24] <AllanJude> the dbuf cache
[20:49:32] <ptx0> AllanJude: btw, would love to get you on my YT channel if you ever make it out to BC, we'll go mountain biking and talk tech at the same time
[20:49:32] <AllanJude> you can just make that bigger if you really want
[20:49:59] <mason> ptx0: No killing AllanJude. We need him.
[20:50:08] <AllanJude> ptx0: not got any events in BC on my schedule at the moment, although I'll be in Bellingham, WA for Linux Fest North West in April
[20:50:21] <ptx0> that's pretty dang close to me in Vancouver :P
[20:50:25] <AllanJude> yes
[20:50:29] <AllanJude> that is why I mention it
[20:50:31] <bunder> building now, this might take a while
[20:50:44] <ptx0> well you might like Vancouver. we have some bridges.
[20:50:46] <AllanJude> bunder: building only took a few minutes for me, in a 6 core VM
[20:50:55] <bunder> slow configure
[20:51:06] *** Dagger <Daggerfirstname.lastname@example.org> has quit IRC (Excess Flood)
[20:51:08] <AllanJude> bunder: yes, configure seems to be slower than compiling for some reason
[20:51:13] <AllanJude> ptx0: Colin Percival lives there, seems to like it
[20:51:22] <ptx0> MilkmanDan: "this heatsink scored 82 and this one scored 34" "cool gimme the 82 one" "but that's temperatures"
[20:51:30] <MilkmanDan> Haha
[20:51:31] <mason> heh
[20:51:40] <AllanJude> ha
[20:51:57] <MilkmanDan> More higher numbers is more better.
[20:52:05] <ptx0> my heatsink went Super Sayan
[20:52:28] <ptx0> saiyan, my bad.
[20:52:57] *** Dagger2 <Dagger2email@example.com> has joined #zfsonlinux
[20:56:08] <AllanJude> zfs send | zstd -T0 --adapt | zstd -T0 -d | zfs recv
[20:56:09] <AllanJude> is very nice
[20:56:43] <ptx0> but pigz makes my cpu all toasty
[20:56:44] <AllanJude> sorry, should be a netcat between the 2 zstd's
[20:56:49] <AllanJude> it varies the compression level based on the network speed
[20:57:00] <AllanJude> so, if cpu is the bottleneck, it lowers the compression level
[20:57:06] <AllanJude> but if the network is the bottleneck, it raises it
[20:57:30] <AllanJude> and of course, zstd has 22 compression levels to vary between, instead of 9
[20:57:46] <ptx0> zstd with auto compression though, that'd be somethin
[20:57:56] <AllanJude> on my todo list
[20:58:00] <AllanJude> I have a plan for how to do it
[20:58:07] <ptx0> hm, now that gives me an idea
[20:58:07] <AllanJude> once I sort out this L2ARC issue, and get zstd merged
[20:58:21] <AllanJude> the idea was to very based on the amount of dirty data, similar to the write throttle
[20:58:25] <AllanJude> er vary
[20:58:36] <ptx0> what about a userspace tool that can pipe random data through zfs checksum/compression algo
[20:58:40] <AllanJude> so, if the disk is the bottleneck, use more compression
[20:58:49] <ptx0> so you can make a 'tar' archive equivalent via zfs
[20:59:08] <ptx0> this sounds stupid until you consider auto compression
[20:59:08] <AllanJude> ptx0: at the last hackathon, Pawel and my idea was one to be able to add zfs encryption to a send stream
[20:59:39] <AllanJude> so zfs send unencrypted | zstreamenc -K ... | network | zfs recv encrypted
[21:00:02] <AllanJude> for backing up to 'untrusted' remote pools
[21:00:04] <ptx0> so i can use foo | zstd | ... but if i ran foo | zcompress --compression=auto --checksum=edonr > foo.zcompressed
[21:00:17] <ptx0> that'd let me have a file with multiple compression algorithms
[21:00:25] <ptx0> and a zfs friendly checksum
[21:00:50] <ptx0> probably a dumb idea but i've never thought of that before vOv
[21:01:22] <AllanJude> in my case at the moment, the sender is an older version of FreeBSD (11.1) that doesn't have compressed send
[21:01:28] <AllanJude> that is why I am using zstd
[21:01:29] <MilkmanDan> What do you mean "auto compression"?
[21:01:42] <AllanJude> MilkmanDan: it varies the compression level
[21:01:42] <ptx0> #5928
[21:01:52] <ptx0> compression level /and/ algorithm
[21:02:00] <ptx0> it'll use gzip or zstd depending on what you want.
[21:02:03] <AllanJude> zstd supports levels 1 - 22, and now has --fast= as well
[21:02:20] <AllanJude> which are 'negative' levels, even faster than the original '1'
[21:02:25] *** Markow <Markowfirstname.lastname@example.org> has joined #zfsonlinux
[21:02:47] <ptx0> #7560 is the rpeplacement for 5928
[21:03:45] <AllanJude> whereas my idea was zfs set compress=zstd-auto
[21:04:36] <AllanJude> and it would vary the zstd level between min and max, based on amount of dirty data. Compress as much as possible, but if data is starting to build up waiting to be compressed and written, lower the compression level, until we are keeping up
[21:07:16] <MilkmanDan> ptx0: I'm lost. What does that have to do with making tars in userspace?
[21:07:42] <bunder> AllanJude: seems to work, its a little on the high side now but one sec i'll paste the results
[21:07:45] <ptx0> MilkmanDan: compression containers usually only allow for one compression algorithm
[21:08:15] <ptx0> MilkmanDan: rar, tar, zip, lz4, bz2 all use a single algorithm for one file
[21:09:04] <ptx0> we'd basically be creating a new compression container that wraps many algorithms and compression levels with metadata that allows a 'zdecompress' tool to inflate it
[21:09:44] <MilkmanDan> ...as part of zfs?
[21:09:49] <ptx0> zfs makes it easy because we've already unified all those algorithms
[21:10:12] <ptx0> you can make any userspace programme do the same thing but it's not as convenient.
[21:12:59] <MilkmanDan> So instead of tar -[zjJ] -xvf tar_file.ext gimmie.txt you'd be able to zdecompress tar_file gimmie.txt?
[21:13:49] <MilkmanDan> I guess I'm not grasping how that's different from what zfs already does transparently.
[21:14:07] <MilkmanDan> I think I need a nap.
[21:15:14] *** Nukien <Nukien!~Nukien@188.8.131.52> has quit IRC (Ping timeout: 268 seconds)
[21:15:26] <mason> Sigh. The Fairphone seems to be European-only.
[21:16:23] <bunder> hm maybe it isn't high, but send doesn't seem to print the last output if the send ends before the next output interval
[21:17:24] *** Nukien <Nukien!~Nukien@184.108.40.206> has joined #zfsonlinux
[21:19:55] <ptx0> MilkmanDan: it's for non-zfs purposes
[21:20:16] <ptx0> i guess you could use zfs send but it's for sending a single file
[21:20:29] <ptx0> like i said it's probably a dumb idea GEEZ SORRY
[21:21:49] <bunder> lol
[21:32:33] <ptx0> mentions casually creating VMs from a 10TiB ZVOL
[21:32:43] <ptx0> what the
[21:33:24] <ptx0> But, If my variation is really only 10MB different from the original 10TB, why shouldn't I be able to pay for 10TB+10MB? -- snapshots + clones give me that. Until the 10TB moves sufficiently that I'm now paying for 10TB (live + 10TB snapshot + 10TB diverged) and my 10MB variation moves so that it's now its own 10TB (diverged from both live and snapshot).
[21:34:04] <ptx0> jeez i dunno what to say there other than "why did you do that"
[21:34:23] <bunder> who has 10tb to spare for only a single zvol
[21:34:47] <ptx0> who the heck has a 10TB VM template
[21:35:47] <bunder> most cloud providers would want like 10 grand just for the block storage
[21:36:08] <ptx0> a lil bit overestimating there
[21:36:15] <ptx0> but yeah it'd be expensive
[21:36:29] <ptx0> it's like $26,000 per month for 100TB
[21:36:52] <bunder> welp time to become an escort i guess hah