[00:00:21] <ss23> I've had no end of trouble of flashing mine the right way too, MTecknology >.<
[00:01:02] <MTecknology> I welcomed in the new year with a DIMM on my old controller taking a dive. I tried to do a simple card swap, but the new controller couldn't identify which disks belonged in the arrays, so now it's rebuild time and I'm finally making the move.
[00:03:17] <MTecknology> I got all the way to step 3 before running into troubles. Booting with the jumper shorted meant I couldn't see the card, and either couldn't find the right utility to flash or just failed to have the level of luck required.
[00:03:22] <ss23> My card doesn't have any official firmware around anymore. I had to find a new version with bugfixes that someone posted on Reddit at some point :(
[00:03:50] <MTecknology> ouch
[00:05:31] <PMT> MTecknology: you should know that LSI cards usually support the cross-controller RAID layout standard DDF, so you could probably have at least read the array from SW RAID
[00:06:13] <PMT> s/support/implement/
[00:06:34] <PMT> (This isn't an especially well known trick, but it does work in my experiences.)
[00:06:56] <MTecknology> oh, interesting
[00:07:36] <PMT> the keyword ddf with mdadm is probably enough to be able to search up how to do the thing if you need to.
[00:08:06] <ptx0> L2 header size (MiB) = 5,727.3
[00:08:08] <ptx0> L2 size (GiB)= 662.3
[00:08:10] <ptx0> holy fuck
[00:08:23] <ptx0> bad l2arc, bad
[00:08:24] <PMT> where's that from
[00:08:24] <MTecknology> yup, that first link already looks awesome
[00:08:37] <ptx0> 'bad L2ARC cache hit rates' on ML
[00:08:41] <PMT> oh lawd
[00:08:48] <ptx0> s/hit rates/hits/
[00:09:21] <PMT> ...how does dedup work on a pool with two different checksums enabled?
[00:09:30] *** Wharncliffe <Wharncliffe!coffee@gateway/vpn/privateinternetaccess/b> has joined #zfsonlinux
[00:09:43] <PMT> (I was just trying to think about stupid ways to inflate ARC misses stupidly)
[00:10:12] <MTecknology> I was able to pull off the data I cared about (vm snapshots), and I have a complete/full set of backups if that wasn't possible, so I'm not crying that the new controller didn't magically work. It's a nice opportunity to finally shift away from hw raid... and start buying *much* cheaper controllers in the future.
[00:10:45] <PMT> ptx0: i wonder if the bug I filed about ARC purging itself wildly thrashes the L2ARC, or if there are cases where things evicted from ARC won't land on L2ARC...
[00:11:10] <Shinigami-Sama> I don't know, last time I tried to buy a real SATA controller with more than 1/2 "real" ports it got up to stupid prices quickly
[00:11:17] <PMT> MTecknology: they're only extremely cheaper compared to the RAID cards with BBUs or similar
[00:11:22] <PMT> "real" ports?
[00:11:34] <PMT> Meaning not behind SATA PMP (god help anyone)
[00:11:47] <Shinigami-Sama> yes "real" not "multiplexed"
[00:12:28] <Shinigami-Sama> I found one 8 port card that looked nice, then read the chipset, and it was a single SATA3 port behind 2(!?!) multiplexers
[00:12:33] <PMT> jfc
[00:12:40] <PMT> what is this a raspberry pi
[00:13:03] <Shinigami-Sama> it was 40$ so I wasn't too surprised honestly, but really... 2 multiplexers?
[00:13:23] <Shinigami-Sama> 1 -> 2 -> 8
[00:14:01] <PMT> I mean, PMP only knows how to go up to 4:1 I believe
[00:14:02] <PMT> so
[00:14:06] <Shinigami-Sama> after that I gave up
[00:14:55] *** rjvb <firstname.lastname@example.org> has quit IRC (Ping timeout: 252 seconds)
[00:17:48] <ss23> >2019 >not running 100% u.2
[00:19:33] <PMT> ss23: I don't think I've ever seen spinning rust with a U.2 (yes i know about the back-compat), and if there's no backplane, ...
[00:21:14] <ptx0> 18:10:51 < PMT> ...how does dedup work on a pool with two different checksums enabled?
[00:21:22] <ptx0> it uses SHA internally always
[00:21:26] <ptx0> aiui
[00:21:46] <PMT> I thought one of the whole reasons to use edonr/skein/sha512 was for dedup
[00:22:05] <ptx0> sha256
[00:22:17] <PMT> No, I meant what I said. I was listing the 3 added ones.
[00:22:25] <Shinigami-Sama> I thought the whole reason dedup sucked was because the hash was captured from blocks that are too small...
[00:22:33] <PMT> Shinigami-Sama: no, dedup sucks for a lot of reasons.
[00:22:47] <ptx0> good luck with those checksum algo
[00:22:53] <Shinigami-Sama> I like it on 2012/2016 servers for accountants and lawyers
[00:22:54] <PMT> Why?
[00:23:09] <ptx0> they are new and thus weird and i do not like them
[00:23:17] <ptx0> do you need any better reason
[00:23:19] <DHowett> accountants and lawyers presumably make backups of their nearly-identical daya with copy+paste+rename
[00:23:21] <Shinigami-Sama> PMT: he is full cumerdigeon
[00:23:22] <DHowett> data*
[00:23:32] <PMT> That's a bold stance from someone who thinks running stable distros is insane. :P
[00:23:39] <Shinigami-Sama> DHowett: ...you've never supported either have you?
[00:23:57] <ptx0> PMT: i'm a bold person
[00:24:21] <DHowett> Shinigami-Sama: i've not supported this type of user, no ;P
[00:24:37] <ptx0> PMT: it has warnings against edonr in the man page for dedup
[00:24:44] <Shinigami-Sama> PMT: I haven't seen a stable distro that kept up with security updates to applications sanely so...
[00:24:48] <ptx0> or rather that using ,verify is required because it's a shitty dedup algo
[00:25:09] <Shinigami-Sama> DHowett: I perfer trucking companies if that gives you any indication
[00:25:11] <PMT> ptx0: I believe it specifically says "out of an abundance of caution" and other platforms don't do that
[00:25:22] <DHowett> Shinigami-Sama: it certainly does
[00:25:22] <ptx0> no, it is mandatory
[00:25:24] <MTecknology> From here (https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS) at step 2.2, it talks about selecting a boot disk. I'm not familiar enough with zfs to understand what I want to do here. If I were using mdadm, I would set up raid1 on two sets of drives, put lvm on top, and make a 1GB /boot and partition the remaining system on it. With ZFS, I'm not sure what this should
[00:25:30] <MTecknology> look like.
[00:25:52] <ptx0> If set to verify, ZFS will do a byte-to-byte comparsion in case of two blocks having the same signature to make sure the block contents are identical. Specifying verify is mandatory for the
[00:25:56] <ptx0> edonr algorithm.
[00:25:58] <PMT> ptx0: "In an abundance of caution, Edon-R can not be used with dedup (without verification)."
[00:26:03] <Shinigami-Sama> MTecknology: do you need grub to boot, or can you efi?
[00:26:10] <Shinigami-Sama> if you can EFI its much much simpler
[00:26:22] <Shinigami-Sama> if you need grub...cry
[00:26:23] <ptx0> PMT: exactly
[00:26:27] <ptx0> it sucks for dedup
[00:26:41] <MTecknology> I'm also an EFI noob... although, my system definitely supports it.
[00:27:23] <ptx0> only run dedup for /boot so i can store my uncompressed dozens of kernels with a 24x dedup ratio
[00:27:49] <ptx0> it's just a 1GB pool so it works quite well
[00:28:03] <ptx0> there are indeed situations when dedup works
[00:28:29] <MTecknology> I was planning on not using dedup, but I like that idea.
[00:31:33] <MTecknology> Should I just do the same thing to all four disks for the partitioning step?
[00:32:50] <PMT> ptx0: I mean, it sucks that you can't use it without verify, but I can't find any evidence that it's actually bad at it or not strong enough to do it, particularly with the salting.
[00:32:55] <ptx0> i've got four partitions, one is esp, one is swap, one is for /boot pool (zfs) and one is for / (zfs)
[00:33:03] <PMT> I had hoped the old reviewboard might remember, but apparently not
[00:33:35] <ptx0> grub-efi installs into part1 (vfat) and loads kernels from /boot on zfs, where dracut unlocks encrypted / pool
[00:34:04] <ptx0> bpool/rpool are both mirrored pools, and on my server it has each disk mirrored for /boot so, 6-way mirror
[00:34:22] <ptx0> that way any individual disk can fail without losing the ability to start the system
[00:37:20] <MTecknology> How many disks have esp and /boot?
[00:37:25] <ptx0> 6
[00:38:11] <ptx0> you'll need to manually install your bootloader into the esp for each disk since no distro i'm aware of manages this for you
[00:38:16] <ptx0> but it's a one time thing, mostly.
[00:38:51] <ptx0> EFI boot is far faster and more reliable than CSM boot though so there's that
[00:39:00] <MTecknology> Do you use a separate /boot for dedup only?
[00:39:09] <ptx0> no, it's for encryption on /
[00:39:18] <MTecknology> ah
[00:39:39] <ptx0> oh apparently i'm not deduplicating /boot anymore
[00:39:56] <ptx0> probably failed to set that when i built this env
[00:40:16] <ptx0> it did make importing the pool rather slow
[00:40:29] <MTecknology> Does encryption need to be applied to an entire pool or can "what are partitions called?" be individually encrypted?
[00:40:46] <ptx0> the feature is pool wide
[00:40:53] <ptx0> you can encrypt individual datasets
[00:41:04] <ptx0> grub won't touch any pool with any feature it doesn't understand
[00:41:12] <ptx0> even if it is readonly compatible
[00:41:43] <ptx0> in general, grub lacks support for zfs features. so use /boot pool and don't worry about it.
[00:41:46] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has quit IRC (Quit: shibboleth)
[00:42:11] <MTecknology> I don't suppose you happen to have a set of step by step instructions you kept for yourself so I could follow along and try to get the same setup, do you? (with two fewer disks)
[00:42:14] <ptx0> it'd be neat if openzfs managed to produce an EFI build..
[00:42:20] <ptx0> nope
[00:42:49] <MTecknology> bummer... I had to ask! :)
[00:42:51] <ptx0> it was fairly trivial to piece it together
[00:43:21] <ptx0> "just install grub-efi to each disk" satisfies a lot of the requirements
[00:43:29] <ptx0> then you just boot from zfs-on-root like normal..
[00:45:42] *** vonsyd0w <vonsyd0w!~vonsyd0w@unaffiliated/vonsyd0w> has joined #zfsonlinux
[00:46:39] <Shinigami-Sama> just chainload eh?
[00:50:06] <MTecknology> I think I'm getting a little confused on that step 2.2 because partition 2 is bios (if you want it), part 3 is efi, and then part 1 is the remaining disk. I'm also not at all familiar with sgdisk so more time in the man page might help that out.
[00:54:54] <MTecknology> Apparently GPT doesn't care what order they show up in. Interesting. This magically makes a lot more sense now. :)
[00:56:14] <ptx0> vOv always installed to MBR when dealing with msdos partition layout
[00:59:03] <MTecknology> It sounds like I should also take this time to drop away from MBR and BIOS in favor of GPT and UEFI.
[00:59:27] <MTecknology> MBR support is a legacy thing, isn't it?
[00:59:33] <ptx0> very
[00:59:56] <cbreak> uefi is old already
[01:01:40] <Shinigami-Sama> its all direct bit streaming these days
[01:01:46] <Shinigami-Sama> self decoding
[01:03:45] <ptx0> my bootloader is a quine relay
[01:08:25] <MTecknology> so... [ (-n4:1M:+512M -t4:EF00 | efi), (-n5:0:+256M -t5:8200 | swap), (-n1:0:+2G -t1:bf01 | bpool), (-n2:0:+20G -t2:bf01 | rpool, w/ encryption), (-n3:0:0 -t3:bf01 | dpool ..data) ] -- Does this seem sane or silly?
[01:16:16] <ptx0> i have no idea what is happening
[01:16:22] <ptx0> i just use parted
[01:16:27] <ptx0> like a normal person
[01:16:44] <ptx0> and then sgdisk -R=/dev/target /dev/source
[01:16:53] <ptx0> copy to target from the initial source mirror disk
[01:17:29] <ptx0> it looks like you split rpool and dpool but that's unnecessary at best and harmful at worst
[01:18:04] <ptx0> one hint with encryption is to create an unencrypted pool and a encrypted dataset within it, for root stuff
[01:18:25] <ptx0> that way you can always create unencrypted datasets if you want, though, i don't, because threadripper is faster than my storage
[01:19:00] <ptx0> i still use rpool (encryption=off) and rpool/ocean (encryption=on) and place everything here
[01:22:06] <ptx0> wish this thing had more than 256gb ssd mirror in it
[01:32:17] <MTecknology> ah, I didn't catch what you meant earlier, that encrypted datasets can be created on unencrypted pools.
[01:33:32] <MTecknology> Is ocean the name of the host?
[01:36:13] <MTecknology> oh... that's usually called 'tank', isn't it?
[01:41:02] <Shinigami-Sama> "tank" is the default pool name
[01:41:08] <Shinigami-Sama> ocean is a dataset in the pool
[01:53:04] <ptx0> there is no default pool name
[01:53:18] <ptx0> that's just what the oracle docs used to keep in line with the use of The Matrix characters
[01:53:31] <ptx0> like trinity would be the server name, communicating with dozer or something
[01:54:10] <ptx0> think i saw a morpheus and a cipher at some point or another in various manuals
[01:54:39] <ptx0> s/oracle/sun/
[01:54:43] <ptx0> oops :P
[01:56:14] <DeHackEd> you caught your mistake and corrected it. you are forgiven
[01:58:20] <MTecknology> I still kinda miss macromedia
[01:58:31] <DeHackEd> no you don't
[02:04:27] <bunder> the security flaw, which has been reported to Microsoft, allows the person in possession of someone's phone to receive a Skype call, answer it without unlocking the handset, and then view photos, look up contacts, send a message, and open the browser by tapping links in a sent message, all without ever unlocking the phone.
[02:04:34] <bunder> didn't apple/facetime just have that bug
[02:04:38] <bunder> or am i having a stroke
[02:07:24] <MTecknology> k, so at 2.3, it's talking about creating rpool. Do I want to create an rpool like it says (w/ -R /mnt) and then bpool (-R /mnt/boot, with the dedup option, without xattr=sa)? Did I even make a coherent question?
[02:11:25] <DeHackEd> as for dedup, don't use deup.
[02:11:34] <DeHackEd> never use dedup
[02:12:07] <MTecknology> ptx0 mentioned it's nice for /boot because of all the kernels
[02:12:51] <DeHackEd> kernels are compressed and zfs uses a pretty coarse block size by default. a boot pool is tiny and would probably be okay, but I don't see it benefitting significantly
[02:14:16] <CompanionCube> are uncompressed kernels even a thing on x86?
[02:14:30] <DeHackEd> only in the same directory you run "make" from
[02:14:45] <CompanionCube> you can't boot a vmlinux though
[02:15:11] <ptx0> you can.
[02:15:14] <CompanionCube> is that the multiboot patch
[02:15:37] <ptx0> The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
[02:15:51] <CompanionCube> ah, so they are a thing
[02:16:01] <CompanionCube> and you do this for dedyp?
[02:16:03] <CompanionCube> *dedup?
[02:16:12] <ptx0> i did once
[02:17:24] <MTecknology> I haven't built my own kernel in years.
[02:17:26] <Shinigami-Sama> its ptx0 ... assume hes done all the stupid things at one point, because unlike me he has motivation :P
[02:17:37] <DeHackEd> hey, that's my job!
[02:17:59] <Shinigami-Sama> I think I tried to talk him into pxe booting a server to test kernel/disk configurations on a bare metal server
[02:18:10] <MTecknology> I'll go ahead and skip dedup on bpool since I'm likely to break something
[02:18:31] <gchristensen> Shinigami-Sama: is that stupid? I do that
[02:18:57] <ptx0> i pxe boot everything
[02:19:13] <DeHackEd> i pxeboot for installation, but it's not like I have diskless servers...
[02:19:31] <MTecknology> My ipxe server is a VM... I don't boot bare metal from pxe. :P
[02:19:42] <gchristensen> most of my servers mount the disk with a randomly generated encryption key, effectively erasing it on every boot.
[02:20:01] <Shinigami-Sama> gchristensen: no no, I mean he was complaining about a regression, so I tried to get him to pxe diffierent kernel/ZFs modules onto baremetal and more or less run ztest
[02:20:06] <gchristensen> ah
[02:20:20] <gchristensen> I do something like that, too, but a bit different :)
[02:20:49] <Shinigami-Sama> I think it was my first real conversation with him now that I think about it
[02:22:00] <MTecknology> I'm trying to understand why this document says to use canmount=off for rpool, and if it should also be on bpool.
[02:23:00] <CompanionCube> mounting a pool's root dataset is not something that is needed
[02:24:38] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has joined #zfsonlinux
[02:25:09] *** PewpewpewPantsu <PewpewpewPantsu!~pewpew@unaffiliated/setsuna-xero> has quit IRC (Ping timeout: 246 seconds)
[02:25:09] *** Shinigami-Sama <Shinigami-Sama!~xero@unaffiliated/setsuna-xero> has quit IRC (Ping timeout: 246 seconds)
[02:25:30] *** tlacatlc6 <email@example.com> has joined #zfsonlinux
[02:31:40] <MTecknology> Do I want canmount=off on all of my pools or just rpool?
[02:33:05] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has quit IRC (Ping timeout: 258 seconds)
[02:36:02] <CompanionCube> up to you really
[02:36:32] <DeHackEd> typically we suggest canmount=off because the root filesystem can't be `zfs rename`'d around to alternate locations. it's best used to carry only the basic properties you want globally inherited
[02:36:45] <DeHackEd> of course, that's an opinion and opinions vary.
[02:36:46] <CompanionCube> setting canmount=off can prevent you from unintentionally writing the root dataset
[02:37:28] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has joined #zfsonlinux
[02:38:11] *** Markow <Markowfirstname.lastname@example.org> has quit IRC (Quit: Leaving)
[02:40:04] <blackflow> in linux, you can't remount existing mountpoints. THANKFULLY. I loathe FreeBSD for remounting root without a peep or any clues it just did so. I asked the secteam for a CVE abut they chickened out of it.
[02:42:37] <ptx0> probably because it was not a security concern
[02:43:45] <blackflow> silent root remounty by virtue of plugging in an usb stick with a zpool ? yeah, not sure it's not :)
[02:43:49] <blackflow> *remount
[02:44:32] <ptx0> lots of evil things can be done to a system
[02:44:37] <ptx0> they do not all warrant a CVE
[02:45:38] <blackflow> bs. swapping out your root filesystem for another, without a peep, in response to plugging in a USB stick is by all possible definitions, a security boundary violation.
[02:46:26] <ptx0> it does not do that in the distributed configuration
[02:46:28] <blackflow> I mean, you do understand there was no root user involved, no authentication, no authorization. a piece of hardware was connected to the device, it contained a zpool with mountpoint=/ and FreeBSD's ZFS happily mounted that.
[02:46:36] <ptx0> you have to enable auto import
[02:47:18] <ptx0> and why would you allow auto import? that's like getting upset about autoplay exploits in 2019
[02:47:26] <ptx0> "duh"
[02:47:30] <CompanionCube> ptx0: or at least ask for confirmation first
[02:47:38] <DeHackEd> all I heard was "physical security compromised, all other bets are off"
[02:48:07] <MTecknology> I'm feeling dense and feel like canmount=x is a big topic, but it sounds like using blindly using canmount=off for everything is relatively safe.
[02:48:23] <MTecknology> "If I can touch your box, it's not your box."
[02:48:30] <blackflow> do I hear a hint of "physical intruder present on the console, forfeiting user authentication because all bets are off"? :)
[02:48:30] <ptx0> blackflow: i mean, freebsd doesn't use secureboot by default and you can evil maid the shit out of the installation, that does not warrant a CVE
[02:49:34] <DeHackEd> security breaches by inserting rogue USB devices aren't anything new
[02:49:45] <blackflow> I'm pretty sure getting the _root_ filesystem rugged out from under you, without a HINT in logs that it did so, definitely warrants a CVE. much smaller things, let a lone a silent root remount, have got a CVE.
[02:50:46] <ptx0> i'm also ignoring that you haven't really provided any evidence for your claims
[02:50:57] <ptx0> i mean, where's the example you sent in asking for CVE
[02:51:14] <blackflow> ptx0: at any rate, it's a MEGA MOTHER of POLA violations. If there's one POLA violation in existence, this is it. Pretty hypocritical for a community of devs that's screaming bloody POLA VIOLATION gore whenever they can.
[02:51:29] <ptx0> blackflow: "at any rate" it did not warrant a CVE
[02:51:52] <blackflow> ptx0: I sent an email to the secteam, they yell at you if you do anything else. I don't recall all teh details now though.
[02:51:56] <ptx0> heck, did you even try to get the issue fixed or did you just whine about them not issuing a CVE
[02:52:10] <blackflow> I'm not a developer.
[02:52:12] <DeHackEd> auto-importing does sount pretty bad overall, and if you did it you should use altroot=xxx for sure... I don't think a CVE is called for though
[02:52:52] <ptx0> blackflow: ah yet another reason you shouldn't be requesting CVEs then :P
[02:53:07] <blackflow> I mean I'm not a C or kernel dev, I wouldn't be able to fix anythinghere. and given that I've contributed to FreeBSD on other fronts, in code, and time and other means, I found myself in position justifying whining.
[02:53:33] <blackflow> ptx0: I could've asked MITRE for one, and I would've gotten it. I just wasn't in the mood to spite the secteam that much.
[02:56:19] <ptx0> so they gave you a little bit of power and it went to your head lol
[02:56:52] <ptx0> well, barely any power
[02:56:56] <MTecknology> heheh... I had someone try to push me into paying a bounty for a "vulnerability" they found. I declined and they decided to offer it anyway, still offering to let me pay a bounty to make them hold off on releasing it. When I found out the "vulnerability" was essentially, "if I set up bad permissions on the file system, logged in users can view the logs", I went ahead and announced it
[02:57:02] <MTecknology> myself.
[02:57:05] <blackflow> ptx0: what are you talking about?
[02:57:07] <ptx0> that's gotta be the least amount of power i've ever seen go to someone's head like that
[02:57:42] <ptx0> and i saw a shopping cart collector yell at an employee-in-training for doing it wrong
[02:59:18] <blackflow> sounds like personal experience?
[02:59:27] <blackflow> I'm sorry it happened to you.
[03:03:13] *** rjvbb <email@example.com> has quit IRC (Ping timeout: 252 seconds)
[03:05:01] <MTecknology> woah, it looks like setting the correct value for ashift can have a massive impact on write speed.
[03:05:15] <CompanionCube> well duh
[03:06:20] <MTecknology> I was just noticing how extreme the impact can be, according to some benchmarks
[03:09:32] <tlacatlc6> is edonr or skein better than sha512? aiui, both are 256 hashes, right? sorry, if i sound dumb, but i get confused when i try to figure it out. lol
[03:11:44] <Setsuna-Xero> MTecknology, just set it to ashift 12 and be happy
[03:11:45] <MTecknology> 512 is a 512 hash..
[03:12:19] <MTecknology> Setsuna-Xero: On my first set of disks, the sector size is 512 bytes, so I think ashift=9 is appropriate, yeah?
[03:12:19] <Setsuna-Xero> power and internet is back again here.. finally a good chance to put the UPS on the modem
[03:13:17] <MTecknology> and ashift=12 for my other set of disks where the sector size is 4096 bytes
[03:14:05] <CompanionCube> MTecknology: dependa
[03:14:10] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has quit IRC (Quit: Qutting)
[03:14:14] <tlacatlc6> lol, yeah. i meant both edonr and skein being 256?
[03:14:23] <CompanionCube> will you ever replace those 512 disks with 4k disks?
[03:15:05] <MTecknology> I suspect that's unlikely
[03:15:28] <CompanionCube> then there's no issue with using ashift=9 for those disks
[03:16:02] <MTecknology> excellent! and if I ever change them out with 4k, then I'll go ahead and rebuilt, remembering the lesson I learned. :)
[03:16:06] <Setsuna-Xero> you've met yourself right MTecknology? you'll swap those out in 2 months or less :P
[03:17:03] <MTecknology> HAHAH!!!
[03:22:38] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has quit IRC (Quit: Leaving)
[03:23:59] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has joined #zfsonlinux
[03:44:20] <MTecknology> awe... :( "cannot set property for 'rpool': invalid feature 'encryption'"
[03:44:54] <MTecknology> It looks like the version of zfs I grabbed from the repos is 0.6.5 and I need 0.7 for encryption
[03:45:34] <pink_mist> no
[03:45:37] <pink_mist> you need git
[03:45:43] <pink_mist> or 0.8 rc2
[03:45:47] <MTecknology> oh
[03:45:54] <pink_mist> it has not been released yet
[03:46:32] <pink_mist> and make sure you have backups
[03:52:27] <MTecknology> That's just scary enough to make me say I'll happily wait for 0.8 before worrying about encryption.
[03:56:27] <CompanionCube> update anyway
[03:56:33] <CompanionCube> just not to 0.8
[03:58:03] <MTecknology> I see 0.7.12 is available in debian unstable. After I finish the installation, I could update to that (probably) pretty easily.
[03:59:17] <MTecknology> (unless there's a pressing reason to do it now, in the live session)
[04:07:21] <Setsuna-Xero> MTecknology, just build from git
[04:07:41] <Setsuna-Xero> zfs is generally stupid stable
[04:09:23] <pink_mist> yes, I'm just very very conservative in what I suggest to other people for their data
[04:11:48] <pink_mist> I'd rather have 1 out of 500 people thank me for insisting they keep backups than having 5 out of 2500 people complain that they lost all their data
[04:12:59] <MTecknology> gpt, uefi, zfs, etc. is new territory to me, so I'm inclined to avoid adding on to the pile of what I could screw up
[04:15:22] <MTecknology> I still need to flash my controller with an efi firmware
[04:15:31] *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC (Ping timeout: 246 seconds)
[04:15:46] <blackflow> MTecknology: 0.7.12 is even in testing and stretch-backports, if you need it
[04:57:17] *** Wharncliffe <Wharncliffe!coffee@gateway/vpn/privateinternetaccess/b> has quit IRC (Quit: Lost terminal)
[04:58:35] *** buu <firstname.lastname@example.org> has joined #zfsonlinux
[05:26:08] *** jasonwc <email@example.com> has joined #zfsonlinux
[05:31:10] *** Shinigami-Sama <Shinigami-Sama!~pewpew@unaffiliated/setsuna-xero> has joined #zfsonlinux
[05:33:47] *** Setsuna-Xero <Setsuna-Xero!~pewpew@unaffiliated/setsuna-xero> has quit IRC (Ping timeout: 240 seconds)
[06:04:04] *** Setsuna-Xero <Setsuna-Xero!~xero@unaffiliated/setsuna-xero> has joined #zfsonlinux
[06:41:14] <MTecknology> apparently PARTUUID is right
[06:56:25] <MTecknology> hrm.... "EFI variables are not supported on this system."
[06:59:22] *** tlacatlc6 <firstname.lastname@example.org> has quit IRC (Quit: Leaving)
[06:59:29] <ptx0> boot from efi live media
[07:01:10] <MTecknology> I think the live image supports it, but I probably have it disabled on the system and haven't flashed an efi firmware to the controller yet.
[07:08:29] * MTecknology pouts at having to pick up installation again when it was soooooo close to attempting to boot into the installed system... despite the expectation something at some point was done wrong anyway.
[07:20:28] <MTecknology> Yup... boot mode was set to legacy. I switched it to uefi and 'modprobe efivars' worked. I know how I'd normally resume a chroot install like this. I'm guessing with zfs it's no different except for the particular mount commands and that bit about 'zfs set devices=off Xpool'.
[07:43:41] <MTecknology> awe... After I booted my system with UEFI, my disks are no longer visible. :'(
[07:48:54] *** gerhard7 <email@example.com> has joined #zfsonlinux
[08:48:05] <MTecknology> and an hour later, I still haven't figured it out! I think it's time to give up for the night, try again tomorrow, and if I can't figure it out after an hour, fall back to bios. (bright side, it's one less partition)
[08:48:14] *** hyper_ch2 <hyper_ch2!c105d864@openvpn/user/hyper-ch2> has joined #zfsonlinux
[09:19:31] <MTecknology> I'm starting to think the solution is to either a) give up and use bios or b) re-flash this card with a downgraded efi firmware (since this version apparently has no efi option) ... which means no smart pass-through, but slightly faster hba mode. (b) may or may not work, so .... screw it. Tomorrow I'll start over with (a) and hopefully get Genbian installed. :P
[09:32:06] <hyper_ch2> I have no idea what this is about
[09:48:14] *** kaipee <firstname.lastname@example.org> has joined #zfsonlinux
[09:50:19] *** rjvb <email@example.com> has joined #zfsonlinux
[10:05:58] *** veegee <firstname.lastname@example.org> has quit IRC (Quit: veegee)
[10:08:13] *** veegee <email@example.com> has joined #zfsonlinux
[10:08:30] <MTecknology> hyper_ch2: My raid controller welcomed in the new year with a dimm taking a dive. I tried to swap cards, but the controller saw different disks and couldn't import the config. Now that I'm at the point of a full rebuild, I'm moving away from hardware raid and, instead of mdadm/lvm/etc., I'm trying out zfs. Since I'm trying out ZFS, and since it seems to require mbr->gpt, I decided to
[10:08:35] <MTecknology> also try bios->uefi. That last one sounded like a simple thing, but it's proving to be a bit of a nightmare.
[10:11:48] *** veegee <firstname.lastname@example.org> has quit IRC (Client Quit)
[10:13:13] <hyper_ch2> I see
[10:18:53] <PMT> MTecknology: ZFS doesn't quite require GPT, but it strongly wants it.
[10:27:45] *** Floflobel_ <Floflobel_!~Floflobel@cosium-152-18.fib.nerim.net> has joined #zfsonlinux
[10:38:24] <MTecknology> PMT: Is there any practical reason to stick with mbr? I've been sticking with it because I had some vague understanding of it and only ever needed one partition that filled the whole disk, but outside of familiarity, it seems like GPT is just MBR + more features.
[10:39:04] <MTecknology> Most of what I'm finding for "mbr vs. gpt" is "which performs better" which... if there's a difference, that would seem remarkably concerning.
[10:39:26] <Lalufu> There should not be any appreciable difference for this
[10:39:36] <Lalufu> unless you're running a C64
[10:39:55] <Lalufu> GPT is a more complicated data structure, but you're not parsing partition tables all day long
[10:40:04] <MTecknology> heh.. I only vaguely recognized what C64 meant
[10:43:58] <lblume> The main difference I've sen is that it changes some practical ways of doing things, in cases like OS selection for multi-booting, and some commandes of system preparation.
[10:50:02] <PMT> MTecknology: not especially.
[10:50:23] <MTecknology> PMT: is it not interesting because it's boring to you or because it's wrong?
[10:50:33] <PMT> ?
[10:50:50] <MTecknology> I thought "not especially" was a reply to "interesting.."
[10:50:53] <PMT> Oh, I was answering "any practical reason", not replying to your interesting.
[10:50:56] <MTecknology> ooooh
[10:51:24] <PMT> MBR can't express drives over...4T? Something like that.
[10:51:51] <MTecknology> that link said 2TB vs. 9.4ZB
[10:52:14] <PMT> Which was, itself, a clever hack to express drives over 8GB.
[10:52:17] <PMT> Ah, yes, 2T.
[10:52:28] <MTecknology> kinda like 32bit and X ram?
[10:53:13] <PMT> Same reason, yes - integer size limits.
[10:54:28] <lblume> Disk partitioning is full of clever hacks from when it was actually useful to save space by packing as much information as possible in a few bytes
[10:55:06] <PMT> I still like GPT's fake MBR partition to ensure older things shit the bed less
[10:56:50] <MTecknology> Heh.. this is reminding me of an issue I ran into with Netware. There was a bug that caused you to run into issues if you ever increased a disk to >2TB. One of the admins increased a "disk" (lun) past 2TB and caused *everything* to become unreadable. After an insane story, I finally got a netware dev (about a decade after netware EoL) and he did some manual hex editing of files to
[10:56:56] <MTecknology> manually apply the very last patch ever released for netware. It was kinda funny because we were one minor point release prior to the last ever released version, and that version addressed exactly one bug. Wanna know what that bug was?..
[10:57:27] <PMT> Womp fucking womp.
[10:58:09] *** Slashman <Slashman!~Slash@cosium-152-18.fib.nerim.net> has joined #zfsonlinux
[11:02:47] <MTecknology> It was funnier yet because I first called the IT Director to approve me spending $300 on some "netware recovery" tool I found online that didn't work. A day later, I realized that tool wasn't going to work. I tried calling Novell and they said they outsourced to one single entity. That entity said all cases are $999, best effort, win or lose. I called the directory to approve it, and he
[11:02:53] <MTecknology> chewed my ass for bothering to ask. "Do you know how much we're losing every hour this is down or how many people are breathing down my neck?!"
[11:04:36] <MTecknology> (sorry... I know that's crazy OT. MBR vs. GPT, and MBR 2TB limit made me think of it)
[11:09:26] <PMT> Life happens.
[11:12:03] <lundman> life finds a way - isnt it
[11:23:57] <PMT> For the quote you mean, it's usually "Life, uh, finds a way."
[11:24:22] <PMT> I usually use "life happens" instead of "shit happens"
[11:51:22] *** simukis <email@example.com> has joined #zfsonlinux
[12:03:51] *** rjvbb <firstname.lastname@example.org> has joined #zfsonlinux
[12:10:03] *** jailbox <email@example.com> has quit IRC (Ping timeout: 245 seconds)
[13:25:03] *** fling <fling!~user@fsf/member/fling> has quit IRC (Ping timeout: 245 seconds)
[13:29:33] *** stefan00 <firstname.lastname@example.org> has joined #zfsonlinux
[13:37:35] *** jailbox <email@example.com> has joined #zfsonlinux
[13:55:27] <PMT> _Yikes_, re: #7970
[14:24:07] *** jasonwc <firstname.lastname@example.org> has quit IRC (Ping timeout: 240 seconds)
[14:28:12] <FinalX> hm, I have a zfs root with ubuntu 18.04, zfs 0.7.5, no uefi (legacy boot) and currently with an ext2 /boot; is it possible/easy to convert to zfs /boot? or do i need uefi for that or something?
[14:30:19] <hyper_ch2> FinalX: do you use encryption or any new features?
[14:30:55] <FinalX> no encryption, and I don't think I am using anything special feature-wise
[14:32:46] <hyper_ch2> you could then give the whole disk to zfs... it will gpt format nad and you'll ahve a small sdx9 partition.. that would be used to store the uefi loader thingy files on it (not sure what the proper name is)
[14:33:14] <DHE> ESP (EFI System Partn)
[14:33:15] *** Markow <Markowemail@example.com> has joined #zfsonlinux
[14:33:33] <hyper_ch2> I have a debian setup like that
[14:33:45] <hyper_ch2> (it was a pain to setup but now it works)
[14:36:31] <FinalX> well, like I said, I don't have UEFI :) and I haven't seen zfs put /boot on 9 auto yet. I did always note that partition though
[14:36:48] <FinalX> plus that's not a zfs boot, is it? doesn't seem to be a pool
[14:36:54] <FinalX> or dataset, rather
[14:37:16] <FinalX> ptx0 was saying he had a /boot on a dataset with (before) dedup on for the many kernels, so got curious :P
[14:37:43] <hyper_ch2> that's also possible but I never accomplished that
[14:41:19] <cbreak> I don't have any specific /boot on my system
[14:41:59] <cbreak> I boot via uefi, to grub stored on an EFI ESP (which is shared with some other boot loaders, among them Clover, which invokes grub)
[14:42:12] <cbreak> and grub loads some initrd stored on the pool somewhere
[14:43:03] <cbreak> seems to work, even with some zfs features enabled
[14:43:15] <cbreak> (mainly lz4 compression support, async destroy and so on)
[14:53:41] <ghfields> Legacy boot, gpt partitioning, whole system on single zfs dataset? Yes. This can be done. It is just a matter of having a bios_grub partition, a grub compatible pool, and the right grub config.
[14:57:47] <cbreak> why bother with legacy boot?
[14:57:58] <cbreak> does it have any advantage?
[14:57:59] <ghfields> no efi
[14:58:05] <ghfields> partition
[14:58:12] <cbreak> that's not really an advantage
[14:58:37] <ghfields> You can let zfs do all the partitioning itself
[14:58:49] <cbreak> you can do that with uefi boot too
[14:58:50] <ghfields> when you feed it a whole disk
[15:00:38] <ghfields> I either do legacy boot, or go all out efi stub boot
[15:00:44] <ghfields> and forget grub
[15:02:07] *** hyper_ch2 <hyper_ch2!c105d864@openvpn/user/hyper-ch2> has quit IRC (Ping timeout: 256 seconds)
[15:02:08] <ghfields> benefit of that is grub no longer will dictate to you which features it will allow on your boot pool
[15:02:28] <cbreak> then, what gets loaded by efi?
[15:02:37] <cbreak> and what in turn loads the initrd? (if you have one?)
[15:03:05] <ghfields> efi loads the initrd from a fat32 partition
[15:03:21] <bunder> in stub booting, the .efi file is your kernel, and you can bake the initrd in the kernel, so it loads that too
[15:03:48] <bunder> as long as your esp is big enough to fit the kernel
[15:04:09] <bunder> my kernels are around 25mb
[15:04:37] <ghfields> Yea... If I am going to put forth the effort to partition the disk myself, I leave ample room in the "non-zfs" partition to do whatever I want.
[15:05:06] <ghfields> 1G+
[15:10:34] <BtbN> Weird approach
[15:10:49] <BtbN> I'm also not going to ever boot without grub or at least some kind of bootloader that can edit kernel commandlines
[15:11:38] <bunder> i think you can do that in efi too
[15:11:56] <BtbN> Not without _some_ kind of bootloader, systemd-boot or something minimal
[15:12:14] <BtbN> You need a small extra partition in either case as well. bios_boot with legacy boot, or the ESP for EFI boot
[15:12:50] <ghfields> efi shell?
[15:13:14] <bunder> no there is a kernel option, one sec
[15:13:16] <BtbN> I'd rather have something where I don't need to google how to use it first
[15:13:41] <ghfields> I was pretty good at ms dos also
[15:13:44] <BtbN> Just hitting e in the boot menu and then having a somewhat proper text editor is nice
[15:14:19] <BtbN> And how would you edit the kernel commandline in the efi shell?
[15:14:45] <BtbN> It just seems highly impractical. Specially as having a proper bootloader is not something that's an insane amount of work.
[15:15:19] <prawn> grub-install is hard yo :)
[15:15:31] <bunder> i can't find it right now, but there is an option to let you edit the cmdline, i'm not sure where it happens though, probably during preboot
[15:16:52] <BtbN> I never heard of that
[15:17:09] <prawn> All the UEFIs I've watched boot had no such thing either
[15:17:29] <lblume> Even with grub, it's good to know there's EFI shell, I've had to reinstall it a few times manually after upgrades went slightly off
[15:18:29] <lblume> The EFI shell is not usually part of the boot, it's started inside the BIOS
[15:18:53] <bunder> its just another efi file, i had to install it on my laptop because i had no efi shell
[15:18:55] <BtbN> That's only on a select few systems that come with an efi shell embedded into the firmware
[15:19:07] <BtbN> Only ever seen it on SuperMicro
[15:19:17] <bunder> then i got bored and installed memtest too :P
[15:19:23] <cbreak> bunder: is it the real kernel?
[15:19:28] <cbreak> or some intermediate kernel?
[15:19:32] <BtbN> There however you now do the BIOS and Firmware updates via it, which is super nice compared how the prior method was using actual DOS
[15:19:47] <bunder> cbreak: is what?
[15:19:58] <cbreak> the thing that's in the EFI partition in that stub booting
[15:20:24] <bunder> its the real kernel, you just copy bzImage to mykernel.efi and stick it in /boot/efi
[15:20:31] <lblume> BtbN: I got it on my old Asus mobo at home
[15:20:35] <cbreak> so you have to update it every time you update the kernel?
[15:20:53] <bunder> i guess so, unless you like broken kernels :P
[15:21:07] <cbreak> and naturally it's not mirrored
[15:21:10] <prawn> Symlink to the limit!
[15:21:56] <bunder> cbreak: its kindof no big loss if you lose it, you can just import and make a new copy, or keep a copy on usb stick
[15:23:17] <ghfields> can't you just put a script in /etc/kernel/postinst.d/ and have it copy to your efi?
[15:23:29] <cbreak> my grub allows me to boot previous initrds with previous kernels I think. Probably in case something breaks
[15:23:38] <cbreak> seems to be automatic with ubuntu
[15:31:31] <bunder> oh also i forgot to mention you can have more than one efi partition, in the case of a mirror or something
[15:31:51] <bunder> but its up to you to keep them both in sync and add the efi menu options
[15:43:17] <cirdan> huh
[15:44:17] <ghfields> Does mdadm metadata 1.0 work on fat32 efi partitions?
[15:44:31] <cbreak> I have like 6 efi partitions
[15:44:33] <cbreak> or 7
[15:44:36] <cbreak> one on each disk :)
[15:45:02] <cirdan> PMT: what did I need installed to repro the zfs error?
[15:45:58] <cirdan> I have systemd-sysv sysv-rc sysvinit-utils insserv initscripts
[15:56:11] *** tlacatlc6 <firstname.lastname@example.org> has joined #zfsonlinux
[15:57:00] <cirdan> I just tried the upgrade and it went smooth
[15:59:56] <BtbN> There is no smart way to move data between seperate datasets of the same pool, is there?
[16:02:48] <cirdan> mv
[16:03:42] *** clete2 <email@example.com> has quit IRC (Ping timeout: 250 seconds)
[16:05:00] *** clete2 <firstname.lastname@example.org> has joined #zfsonlinux
[16:09:02] <Lalufu> no
[16:09:06] <Lalufu> just the hard way
[16:14:34] <ajs124> If zpool -v tells me that there is a permanent error in "<0xffffffffffffffff>:<0x1>", is there any way I can fix that?
[16:17:42] <PMT> cirdan: you need those installed and to install the stretch-backports version of 0.7.12 that got pulled from the repo
[16:17:52] <PMT> Rather, not pulled, but rapidly iterated
[16:18:19] <PMT> oh sorry, no, you need the one in testing, 0.7.12-1, not the bpo one, my memory is fuzzy. He pulled it from the backports package for that reason.
[16:25:54] *** jasonwc <email@example.com> has joined #zfsonlinux
[16:27:55] <cirdan> yeah i got no error
[16:28:11] <cirdan> i grabbed the unstable one which still has the files
[16:34:27] <PMT> I wonder if it only happens on upgrade.
[16:37:44] <cirdan> thats what I did, an upgrade
[16:42:36] <bunder> ajs124: depends where it is, it could be a snapshot, or it could be pool internal structures
[16:42:57] <bunder> any idea how it wound up like that?
[16:45:22] <PMT> cirdan: I can try to repro it again, but the conditions I gave about insserv are the ones for apt to suggest removing init et al; I haven't tested under what conditions the upgrade failure happens, I was just working from someone having said that having insserv installed was the key problem, and removing it made the problem go away (albeit potentially for vacuous reasons - e.g. if you have no sysvinit
[16:45:28] <PMT> support, then nothing will try processing those scripts, no)
[16:46:05] <cirdan> well seems it was more than just having insserv installed
[16:46:44] <ajs124> bunder, so basically, a drive dropped off the system (one raidz1) and I might have disconnected another drive acidentally, but I'm not 100% sure about any of this.
[16:47:18] <ajs124> now the system hangs with some weird trace in dmesg when I try to start a scrub
[16:47:56] <PMT> cirdan: not having insserv installed (or having testing insserv installed) is sufficient for the problem to not occur.
[16:48:22] <bunder> you could file a bug but it might boil down to you having to recreate the pool unfortunately
[16:48:24] <cirdan> I had the stretch insserv installed
[16:48:39] <PMT> I believe you, I'm merely specifying the constraints I am reasonably certain are true.
[16:48:50] <cirdan> yeah i understand
[16:48:54] <PMT> (technically what happens in testing/unstable is the same error happens but is nonfatal, but vOv)
[16:51:08] <cirdan> i feel (still) that aron jumped the gun if he didn't even repro it
[16:51:26] <bunder> ajs124: that should have been fixed by now unless you're running one of the bad versions
[16:51:41] <bunder> er kernel versions
[16:51:48] <PMT> cirdan: at least Mo has reproduced it, AIUI.
[16:52:20] <cirdan> hmm
[16:52:37] <PMT> I don't even think I disagree with him reverting it rather than letting it break people, while a better solution was found. I think the lack of communication about it a priori was probably not ideal, given how charged this is for some people, but.
[16:54:55] <ajs124> bunder, I think I had mq enabled manually + I run 4.14 on NixOS with unstable zfs
[16:56:17] <cirdan> maybe there's a bad insserv version floating around
[16:56:17] <PMT> ajs124: I don't _think_ the blk-mq bug was backported into 4.14 in any released version. If you're running git nightly kernel versions maybe, but then I have more questions.
[16:56:30] <PMT> I don't think so?
[16:56:52] <PMT> The insserv package in stretched was last updated in 2016.
[16:57:06] <PMT> stretch, even.
[16:57:16] <cirdan> well like i said I did a strech install and couldn't repro
[16:57:23] <cirdan> so maybe im missing something
[16:58:03] <PMT> Feel free to chime in on the bug asking
[16:58:10] <cirdan> yeah I did
[16:59:40] <ajs124> PMT: It seems to have been in there, as my system now hangs with a different dmesg trace. Yay.
[17:00:10] <ajs124> Although that might just be a coincidence
[17:05:42] <PMT> cirdan: I mean, I initially found a bug report from someone on Ubuntu having a similar issue before, which I included in the initial bug report, so it's not as though this is a strange issue only on my one system.
[17:05:52] <ajs124> This is all my setup is telling me right now, any ideas?
[17:06:33] <PMT> ajs124: the blk-mq bug would cause corruption, not "the system is blocking".
[17:06:52] <ajs124> PMT: That's good for me then, I guess?
[17:08:54] <PMT> cirdan: so you installed a custom patched 0.7.11 then upgraded and you're surprised it didn't break the same awy?
[17:13:17] *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #zfsonlinux
[17:14:52] <cirdan> no I installed the backport 0.7.11
[17:15:35] <PMT> Ah, I thought you'd patched it b/c you said "0.7.11 with init scripts", when they didn't have those until 0.7.12.
[17:16:23] <cirdan> no 0.7.11 had it iirc
[17:16:32] <cirdan> no?
[17:16:39] <PMT> Check the changelog.
[17:16:50] <cirdan> maybe I screwed it up by installing 0.7.12 before insserv
[17:16:59] <PMT> ...
[17:17:09] <PMT> Since the problem is insserv running when you install 0.7.12, yes, that would be it.
[17:18:00] <cirdan> i reinstalled 0.7.12 and it didn't trigger
[17:18:47] <cirdan> ah ok that did it
[17:18:54] <cirdan> strange though
[17:20:26] <cirdan> ok that's the problem
[17:20:41] <cirdan> they have a circular dep
[17:21:02] * cirdan rolls his eyes till they are backward
[17:22:56] <cirdan> these guys... totally nnumping the gun and not reading the damn error message. dpkg *said* what the error was even.
[17:24:29] *** almostdvs <firstname.lastname@example.org> has quit IRC (Ping timeout: 268 seconds)
[17:26:56] <PMT> cirdan: exactly what circular dep do you think it is, here?
[17:28:16] <cirdan> You have zfs-zed set to depend on zfsutils-linux, but you have a hard dependency on the zfs-share init file for zfs-zed.
[17:28:55] <cirdan> the fix is to remove zfs-zed from the Required-[Start|Stop]: line
[17:29:08] <cirdan> do that and everything is ok
[17:29:44] <cirdan> dpkg --configure -a finishes setting up the 2 packages and exits cleanly
[17:30:51] <PMT> cirdan: except for if zfs share actually requires zfs-zed running to function.
[17:30:52] <cirdan> doesn't look like the systemd file cares about zed being started
[17:31:05] <cirdan> then the solution is to move zfs-share to zfs-zed
[17:31:23] <cirdan> and why doesn't the systemd service file require zed?
[17:32:29] <PMT> I couldn't tell you. Have fun, I'm dropping my CC from this bug, I'm tired of hearing about it.
[17:34:16] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 250 seconds)
[17:34:34] <cirdan> mm the manpage doesn't sat zed must be running
[17:36:26] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #zfsonlinux
[17:44:17] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has joined #zfsonlinux
[17:44:23] <DHE> ZED isn't strictly mandatory, but many of the automatic features of ZFS like autoreplace depend on it to do the actual heavy lifting
[17:45:01] *** dadinn <dadinn!~DADINN@188.8.131.52> has joined #zfsonlinux
[17:45:48] <cirdan> right but calling zfs share -a doesn't require zed, right?
[17:45:55] <cirdan> It's helpful to have it running though
[17:46:47] <cirdan> the init uses zfs_action
[17:48:29] <ptx0> if you disable zed you don't get syslog entries of zfs checksum events etc
[17:48:37] <ptx0> think carefully
[17:48:58] <cirdan> yeah totally not required
[17:49:18] <ptx0> depends if you ever want to know what is happening to a system
[17:49:26] <cirdan> no, not in this case
[17:49:37] <cirdan> I'm specifically talking about the zfs-share init file
[17:53:21] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 250 seconds)
[17:54:15] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #zfsonlinux
[18:07:38] *** f_g <email@example.com> has quit IRC (Ping timeout: 250 seconds)
[18:20:41] *** Markow <Markowfirstname.lastname@example.org> has quit IRC (Quit: Leaving)
[18:21:15] *** f_g <email@example.com> has joined #zfsonlinux
[18:22:03] *** mmlb <firstname.lastname@example.org> has quit IRC (Ping timeout: 246 seconds)
[18:24:29] *** jasonwc <email@example.com> has quit IRC (Read error: Connection reset by peer)
[18:28:42] <ghfields> was com.intel:allocation_classes feature included in 0.8.0-rc1 removed from 0.8.0-rc2?
[18:29:11] <cirdan> I dont think so?
[18:31:21] <ghfields> Ah... I see... it was renamed com.intel:allocation_classes to org.zfsonlinux:allocation_classes
[18:32:34] <ghfields> I told the zfs-functions.py found on zgrep to look at all versions, instead of just the most recent of the major versions and saw that oddity.
[18:40:35] <DHE> #7920
[18:45:16] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[18:45:56] *** fs2 <email@example.com> has joined #zfsonlinux
[18:51:21] <PMT> ghfields: renamed between rc1 and rc2? That's kinda surprising.
[18:51:49] <ghfields> according to the man page that was pulled from the script. I haven't pulled them myself
[18:53:43] <ghfields> ... and the PR referenced by DHE
[18:54:05] <ghfields> thanks
[18:54:31] <bunder> DHE: your line numbers are wrong :P
[18:54:59] <bunder> oh it was merged already lul
[19:03:47] *** kaipee <firstname.lastname@example.org> has quit IRC (Remote host closed the connection)
[19:05:34] <ptx0> lol @ #8237
[19:05:43] <ptx0> that guy's system really took a dump
[19:06:08] <ptx0> "rebuilding raidz is so much safer than mirrors"
[19:06:13] <ptx0> aahahaha
[19:06:27] <cbreak> raidz2 is safer :)
[19:06:32] <cbreak> (than two disk mirrors)
[19:06:32] <ptx0> he's on raidz3, son.
[19:06:39] <cbreak> well, even better
[19:06:47] <ptx0> no, it really isn't
[19:06:57] <cbreak> it can tolerate 3 disks failing
[19:07:01] <cbreak> so 2 more during resilvering
[19:07:10] <ptx0> if the rebuild thrashes more and burns more disks during rebuild, takes longer, it is more likely to kill off disks
[19:07:11] <cbreak> mirrors can not tolerate a single bit error during resilvering
[19:07:16] <ptx0> mirror is just a simple copy job
[19:07:28] <cbreak> that doesn't change this simple fact
[19:07:30] <ptx0> you are being ignorant and i'm not sure if it's purposeful or not
[19:07:33] <cbreak> that you have no redundancy during resilvering
[19:07:44] <ptx0> you can have three way mirrors, genius
[19:07:58] <cbreak> sure. If you can afford the disks
[19:08:11] <ptx0> same with raidz3, see how his failures cascaded
[19:08:13] <cbreak> then you have about as much redundancy as raidz2
[19:08:17] <ptx0> oh yeah, i forgot
[19:08:21] *** ptx0 sets mode: +q $a:cbreak
[19:08:33] *** ptx0 sets mode: -o ptx0
[19:10:21] *** cbreak <email@example.com> has left #zfsonlinux
[19:11:17] <PMT> forgot what?
[19:16:50] *** Floflobel_ <Floflobel_!~Floflobel@cosium-152-18.fib.nerim.net> has quit IRC (Remote host closed the connection)
[19:20:46] <gchristensen> apparently to +q $a:cbreak
[19:25:54] <Setsuna-Xero> that he doesn't deal with "those types" of people?
[19:26:08] <ptx0> no
[19:26:13] <ptx0> they are ban evading
[19:26:23] <gchristensen> oops
[19:27:23] <PMT> ?
[19:27:27] <PMT> Howso?
[19:33:43] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[19:34:20] *** fs2 <email@example.com> has joined #zfsonlinux
[19:35:04] *** shibboleth <shibboleth!~shibbolet@gateway/tor-sasl/shibboleth> has quit IRC (Quit: shibboleth)
[19:40:53] *** fs2 <firstname.lastname@example.org> has quit IRC (Quit: Ping timeout (120 seconds))
[19:44:39] *** fs2 <email@example.com> has joined #zfsonlinux
[19:49:29] *** Slashman <Slashman!~Slash@cosium-152-18.fib.nerim.net> has quit IRC (Remote host closed the connection)
[19:52:33] <Setsuna-Xero> ptx0: new year new array eh?
[19:52:53] <Setsuna-Xero> that sounds like the type of problem MTecknology will get himself into
[19:53:19] <Setsuna-Xero> ..I should probably install this other 6TB drive so I can mirror my data drive...
[19:54:15] <gchristensen> eh, who needs redundancy
[19:54:40] <MTecknology> redundancy is for wimps with weak backups!
[19:55:07] <Setsuna-Xero> wait I thought rundancy was backups..
[19:55:22] <gchristensen> bingo
[19:59:47] *** stefan00 <firstname.lastname@example.org> has quit IRC (Quit: stefan00)
[20:05:28] <MTecknology> Setsuna-Xero: What's the type of problem I'd get myself into?
[20:05:54] <Setsuna-Xero> #8237
[20:06:52] <ptx0> mm, pumped 3GB of text to php similar_text() method
[20:06:59] * ptx0 waits
[20:07:20] <MTecknology> trying to make big disk modifications during disk recovery sounds like a bad idea, doesn't it?
[20:07:46] <ptx0> #YOLO
[20:07:46] <PMT> To many people, yes.
[20:07:53] <PMT> Some people like living in danger.
[20:08:03] <MTecknology> lol
[20:08:18] <ptx0> this guy woke up this morning thinking, i'm gonna fuck shit up
[20:08:45] <Setsuna-Xero> I dono, I've been in that situation before. "fix it beofre end of day" "but uh... we need to to let it do its things" "No delete all the old data so it fixes itself faster"
[20:09:13] <Setsuna-Xero> I"m thankful I don't have that client anymore
[20:09:19] <PMT> ptx0: Why do you think it would have gone better if they'd just waited for the resilvers to finish?
[20:09:43] <PMT> actually, that pool is a lot of confused.
[20:09:46] <MTecknology> Setsuna-Xero: One of the best things an IT person can learn is how to politely say "screw off"
[20:10:10] <PMT> It claims to be done resilvering while also listing replacing.
[20:12:02] <MTecknology> I learned my my lesson in "the great netware incident of gss". We could have soooo easily avoided about 50-100 man hours between two admins if I'd just had the tact to make sir-freakout sit down and listen to reason.
[20:12:04] <Setsuna-Xero> MTecknology: I learned to hide behind my boss on stupdi things like that, make them talk to the owners after my usual "this is a really bad and stupid idea" didn't work
[20:12:25] <MTecknology> sir-freakout was the it directory and my boss was on vacation
[20:16:42] *** Essadon <Essadon!~Essadon@81-225-32-185-no249.tbcn.telia.com> has joined #zfsonlinux
[20:18:56] <MTecknology> his solution: keep using our temporary version, make it permanent, back up all of the recovered system (100% intact as of last second files were accessed), and restore over top of the temp system people were told to not make modifications to (since they didn't like forcing read-only), prioritizing files people asked for
[20:19:36] <MTecknology> my solution: screw the people that didn't copy files to their desktop like they were told, bring the old system back up, and use the temp box to grab those few files that people requested
[20:20:18] <MTecknology> one hour plus X one-offs vs. a full month long project
[20:22:20] <PMT> How'd that go?
[20:23:01] <Sketch> probably for a full month ;)
[20:23:56] <MTecknology> yup :P
[20:24:02] <Setsuna-Xero> well I assume sir freakout still got his bonus, so "situation normal"
[20:24:36] <MTecknology> the OT was nice, but waking up 3x/night was not
[20:24:37] <Sketch> unfortunately IT directors are not usually IT people...
[20:25:18] <MTecknology> Oh! I didn't include the bestest part!! Because of single-threading and other limitations, backups/restorations had to be done via a WinXP box
[20:27:15] <MTecknology> The particular directory thought he was a brilliant IT god because he helped design and build the initial environment, and managed it before he became director. He'd always share a perl module that "totally did what [I'm] spending hours trying to build, so I should just use perl already" since him finding the module was basically doing my job for me
[20:33:19] <PMT> How helpful.
[20:33:52] <PMT> One of the more esoteric experiences I got to improve was when I automated user account creation on a machine running Python 2.1 or something like that in 2010.
[20:34:26] <PMT> (The instructions said to edit passwd/group/etc by hand and then regenerate NIS by hand, and I thought this was an unfortunate choice.)
[20:34:33] <PMT> (It was also on a Solaris 8 box.)
[20:40:15] <MTecknology> That sounds like it was at least an interesting project
[20:52:22] <MTecknology> "zpool create [...] -O mountpoint=/ -R /mnt rpool [...]"
[21:05:18] *** jasonwc <email@example.com> has joined #zfsonlinux
[21:06:22] <ptx0> my desk is finally here
[21:06:35] <ptx0> i think the UPS delivery lady has a fondness for my face
[21:07:04] <ptx0> she carried the desk into the house and up the stairs while i'm all, uh, er, hey, uh, i can, take that.. o...k...
[21:09:22] *** almostdvs <firstname.lastname@example.org> has joined #zfsonlinux
[21:10:38] <futune> assembling new nas, when moving the chassis i hear something rattling, searching finds a loose mobo jumper at the bottom
[21:10:45] <futune> this ever happen to anyone?
[21:13:19] <futune> if anyone has a supermicro a1sai, could you confirm that there should be an undocumented jumper on pins 6-7 of connector JD1?
[21:13:31] <futune> sorry for offtopic
[21:14:03] <ptx0> uhm
[21:14:26] <ptx0> call supermicro
[21:17:03] <futune> I'll look into that, but I'm very far from america
[21:18:08] <ghfields> MTecknology: They have it that way for the Ubuntu 16.04 and 18.04 wiki entries also. I don't know why they took the effort to write it that way.
[21:18:30] <ptx0> futune: you could email them
[21:18:56] <ptx0> futune: use google voice or some other free termination service for toll-free calls
[21:18:56] <futune> that's a good idea
[21:19:02] <ghfields> future JD1:Power LED/Speaker Header(Pins 1-3: Power LED, Pins 6-7: Internal Buzzer, Pins 4-7: External Speaker)
[21:19:37] <ptx0> i used to have a magicjack connected to asterisk pbx via a 56k vmodem
[21:20:11] <ptx0> used it to make free long distance calls to the US from Canada by calling a canadian number on my PBX that had unlimited minutes
[21:20:11] <futune> ghfields, yeah, my theory is that pins 6-7 should be shorted to use internal speaker
[21:20:29] <ptx0> that might make sense
[21:20:36] <futune> but the jumper is not on the list of jumpers in the manual, or documented
[21:20:38] <ptx0> if anything it's a convenient place to store it
[21:20:43] <ptx0> ;)
[21:20:44] <MTecknology> ghfields: thanks! If you're not sure, then I'm going to try omitting it and not get cranky if it causes a problem. :)
[21:20:53] <ghfields> If I remember right, speaker connectors are usually 4 wide, hence the 4-7.
[21:22:24] <futune> MTecknology, I have root on ZoL 6.5 on debian stretch, did not set mountpoint for pool
[21:22:29] <futune> nor would that ever occur to me
[21:23:19] <futune> but then again I always install debian via debootstrap and manually set up a bootloader
[21:23:22] <ghfields> MTecknology: I only set mountpoint on dataset to use for root. I don't don't mess with "canmount" stuff either.
[21:25:57] <MTecknology> I feel the urge to create a PR whenever I finish walking through this. :)
[21:26:26] <ghfields> I have no problem with the pool name showing up on / to act as a container for any other datasets with unspecified mountpoints.
[21:27:11] <MTecknology> ooooooh....
[21:34:13] <MTecknology> I see <pool>/ROOT/debian, and it seems common to use <pool>/<something>/<foo>, but <something> appears to be optional. Is that just there for organization and bulk operations or does it have other purposes? It looks like omitting it makes that thing you just mentioned with an unspecified mountpoint work.
[21:37:10] <futune> ghfields, I have that very pdf open, how did I miss that?
[21:37:17] <futune> thanks for clearing up my headache
[21:38:33] *** jugo <jugo!~jugo@unaffiliated/jugo> has quit IRC (Ping timeout: 268 seconds)
[21:40:46] <ghfields> MTecknology: It is the way it has done. ROOT historically was used by solaris beadm to hold the boot datasets
[21:41:17] <ghfields> It can be used for upgrades or storing other distros.
[21:43:30] *** fp7 <fp7!~fp7@unaffiliated/fp7> has joined #zfsonlinux
[21:50:59] <MTecknology> ghfields: thanks for explaining
[21:58:35] <FireSnake> 193G scanned at 2.05G/s, 5.10M issued at 55.5K/s, 2.67T total
[21:58:48] <FireSnake> what does 'issued' mean in zpool status?
[21:58:54] <FireSnake> when scrubbing
[21:59:07] <FireSnake> can't find this either in the faq or manual
[22:00:35] <CompanionCube> MTecknology: great netware incident?
[22:05:04] <CompanionCube> overflow is fun
[22:06:16] <MTecknology> you can click 'soft wrap' and it'll wrap for you
[22:06:44] <MTecknology> I was about to paste elsewhere and just noticed that
[22:06:57] <CompanionCube> I meant
[22:07:10] <CompanionCube> not that kind of overflow
[22:07:42] <MTecknology> ooh, lol
[22:08:36] <Setsuna-Xero> I was sure I had 4billion pennies here before I dumped that last jarfull in...
[22:09:12] <PMT> FireSnake: ZoL 0.8.X reorders scrubbing IOs so it iterates over the metadata to figure out how to order it (scanning) and then issues it in sequential chunks (issuing)
[22:09:46] <PMT> If you want to read more about it, "sequential scrub" is the phrase you want to search
[22:18:49] <FireSnake> PMT: ah, thanks, so 'issued' is how many IOs were reordered
[22:19:02] <FireSnake> in order to achieve optimal sequential reads
[22:21:18] <PMT> FireSnake: no, issued is how much it's actually done the scrub on so far
[22:33:42] *** Xeha <Xeha!~Xeha@unaffiliated/k1773r> has quit IRC (Ping timeout: 246 seconds)
[22:42:30] <MTecknology> Whoever is in charge of writing the zfs man page needs a cookie. I learned a lot from the portion I just read through.
[22:43:31] <PMT> "in charge of"
[22:44:41] <MTecknology> "responsible for"?
[22:45:39] <PMT> I mean, run git blame, but it'll tell you that's quite a lot of people.
[22:46:06] <CompanionCube> may as well also read zpool(8) and maybe zpool-features(5)
[22:46:53] <PMT> git blame also thinks the answer is 35, using some Q&D text parsing and only the lines still there in latest git.
[22:47:08] <PMT> It's probably higher since the man pages were reformatted at one point so I think it'd be missing those bits.
[22:47:36] <MTecknology> I was mostly commenting that I think it's an excellent man page and that makes me excited.
[22:48:05] <PMT> Sometimes it's incomplete or inaccurate, but people try to clamp down on those if they come up.
[22:49:27] *** gerhard7 <email@example.com> has quit IRC (Ping timeout: 246 seconds)
[22:55:54] *** fp7 <fp7!~fp7@unaffiliated/fp7> has quit IRC (Ping timeout: 252 seconds)
[23:02:41] *** Xeha <Xeha!~Xeha@unaffiliated/k1773r> has joined #zfsonlinux
[23:22:11] *** Markow <Markowfirstname.lastname@example.org> has joined #zfsonlinux
[23:42:10] *** clete2 <email@example.com> has quit IRC (Ping timeout: 250 seconds)
[23:44:33] *** clete2 <firstname.lastname@example.org> has joined #zfsonlinux
[23:49:52] <MTecknology> awe...
[23:49:59] <MTecknology> "grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible. grub-install: error: filesystem `zfs' doesn't support blocklists."
[23:50:47] <PMT> That is correct.
[23:51:08] <Setsuna-Xero> thats why you needed to sgdisk with certain flags
[23:51:24] <Setsuna-Xero> so grub can tell where its supposed to dig its claws into
[23:51:30] *** clete2 <email@example.com> has quit IRC (Ping timeout: 258 seconds)
[23:52:29] <MTecknology> ooooooh, shucks, I see what I missed
[23:52:56] *** clete2 <firstname.lastname@example.org> has joined #zfsonlinux
[23:53:51] <MTecknology> thanks for making me jump back to sgdisk :)
[23:54:05] <Setsuna-Xero> yw, I do that same thing regularly
[23:55:59] <jasonwc> heh, that reminds me of the time I was creating a root pool and used the correct sgdisk commands to partition the disk but then passed the entire disk to ZFS, thereby negating what I had done :/
[23:56:06] <jasonwc> did that a few times before realizing my error
[23:56:42] <futune> turned the new nas on, no mobo beep codes :D
[23:56:50] <MTecknology> I completely missed the step for creating the bios partition
[23:57:02] <Setsuna-Xero> futune: did you remember to plug in the PC speaker? ;)
[23:57:16] <jasonwc> lol
[23:57:36] <futune> yeah, we had a big discussion about it earlier actually
[23:57:47] <futune> cause the jumper that sets it to use the internal one had come loose
[23:58:01] <futune> (I just found a loose jumper at the bottom of the case... scary!)
[23:58:08] <Setsuna-Xero> oh I remember that, pins 6=7
[23:58:09] *** donhw <email@example.com> has quit IRC (Remote host closed the connection)