00:47:32 I think it should be okay to keep builtins around and take other snapshots as things change and on an as needed basis. 00:47:43 At least, that would be my general disposition / expectation. But I dunno. 10:10:31 hello all, a simple question regarding to ZFS: if there is only SSD for a machine, eg: 12 * 7.6T ssd, do you advice slog? and what’s the raid is recommand? mirror / raidz1 or raidz2 ? best wishes 12:06:54 No just use slog if you can at least mirror it, however ArcL2 is ok. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAIDZ.html 12:07:42 No recomdation depends on your usage pattern/availability etc 13:25:12 generally, having a separate slog device is useful when it noticably faster than the rest of the storage in the pool 13:25:23 e.g. SSD slog, HDD disks in the pool 13:25:45 if it's already SSD, having a separate slog device is likely not to be as useful 13:26:57 since it's the log, so (broadly speaking) I/Os get written there first 13:27:49 so if it's the same speed as the rest of the disks in your pool, you're artifically bottlenecking yourself 13:28:17 (I've seen this happen where someone created the log device on another HDD and the complained their pool was slow :P) 13:58:37 heh.. i think i'm going to have to knock some heads while i'm at the office next week 13:58:48 jbk: although I believe having a slog that's at least as fast as the pool can still be useful for cutting down on fragmentation iirc 13:59:59 but it kills your performance unless the pool is basically a single disk 14:00:25 because you end up only being able to write as fast as that slog device 14:50:03 again, that's usage dependent. 14:50:30 Though I can't think of a usage where having a single-drive write speed is optimal. 20:31:11 Hello! I was trying to passthrough the USB ports in my server to a bhyve VM as a dirty hack to install Windows Server 2022, I mapped the PCI address of the USB controller in /etc/ppt_aliases and /etc/ppt_matches and after rebooting the active BE fails to boot complaining that it cannot read the pool label and therefore it cannot mount root. 20:33:16 I'm able to boot with an older BE and mount the failing root zfs filesystem and access it. So far I've deleted the /etc/ppt_* files, deleted /etc/zfs/zpool.cache, I have booted from an install ISO and imported and exported the pool, disabled and enabled the BE, created a new BE based on it and trying to boot it... But I still get the same error. 20:34:27 It's not critical since I could go back to the old BE, reinstall some packages and copy the config files from the broken BE, but I really would like to know what I messed up and how to fix it. 20:36:18 The full error message in the console is NOTICE: Performing full ZFS device scan! 20:37:25 NOTICE: Cannot read the pool label from '/pci@0,0/pci103c,870c@17/disk@2,0:b' 20:37:46 NOTICE: spa_import_rootpool: error 5 20:38:28 Cannot mount root on /pci@0,0/pci103c,870c@17/disk@2,0:b fstype zfs 20:38:47 hrm.. 5 is EIO which isn't particularly helpful 20:38:48 that's EIO trying to read the label from that device 20:38:49 I'm running OmniOS r151046 20:39:11 it might mean the device in the pool config is not correct, and we can't find where it now is 20:40:33 But I'm able to boot from the old BE which is just a different FS on the same pool 20:41:29 have you scrubbed the pool? 20:41:37 No 20:41:44 Should I? 20:42:01 my only idea is maybe it really has got issues reading the new BE, if everything else semes to work, but you might want to wait for someone more expert to agree with me (or not) 20:44:11 Could be.. I hadn't thought about it... Because in the 1st reboot it must have been accessing the filesystem, then read the /etc/ppt_* files, mapped the pci thing which apparently also had the root disk hanging off it to the ppt device and immediately lost access to it 20:44:33 I'll try the scrub, thank you! 20:46:43 I'm not sure if ppt info is stored anywhere else that may have not got nuked, pmooney would be the one who knew that 20:46:51 and jbk probably your best bet of people currently awake for zfs 20:48:06 or sjorge, honestly 20:48:30 I've not had a big hand in the ppt stuff, besides continuing maintenance 20:48:51 yeah, i've not done anything really with ppt 20:49:17 and i think Woodstock is on vacation (ISTR he did a lot of the PPT work) 20:49:33 yeah, he did a bunch of the porting work 20:50:31 you could maybe try booting w/ kmdb and poking around with ::prtconf to see if that device is there 20:50:47 though I have no idea if that was getting passed-thru what it would look like in that 20:50:53 or what to look for 21:08:29 The scrub worked! 21:08:56 It reported 0 errors, but I rebooted just in case and it booted the main BE fine 21:09:38 It's behaving a little weird, I have no IP address now but that probably is a separate issue 21:10:49 I'll get to fix that and keep an eye on it, thank you very much for your help! 21:11:27 I have been using illumos for a few weeks only but it really feels very solid and reliable, I'm liking it a lot 21:25:19 that is... odd 21:36:18 Maybe the scrub made it refresh some internal device identifiers or something?.. I don't know the inner workings 21:36:59 yeah.. 21:37:44 the only think I can think of (and this is a stretch) is that maybe the disk name (e.g. c0t0d0) changed because of the pass-thru so maybe the cache file was wrong? 21:37:47 The ip thing was me disconnecting the ethernet cable while I was fiddling with cables to connect a monitor and keyboard to it to debug why it was not booting... :) 21:37:56 though i think it should still be able to figure things out 21:38:20 pilonsi: it's always nice when it's a simple fix :) 21:39:12 Yeah, and the other be could boot fine off that disk as well.. its strange 21:39:33 Anyways I should start getting used to creating backup bes before I do weird thing 21:39:35 well the cache is per-BE 21:39:44 though also... that might end up in the ramdisk... 21:39:46 not sure offhand 21:39:50 (just thinking out loud) 21:40:08 I did delete the /etc/zfs/zpool.cache file just in case, but it made no effect 21:41:00 Unless it has some other cache, pool information, etc.. files stored under / ? 21:45:02 pilonsi: you deleted from mounted dataset of failed BE or booted dataset? 21:49:45 from mounted dataset of failed be 21:56:59 pilonsi: Can you check whether 'prtconf -v' find that device path '/pci@0,0/pci103c,870c@17/disk@2,0:b' ? 22:00:04 pilonsi: something like this: prtconf -v |grep -A 2 'dev_path=/pci@0,0/pci103c,870c@17/disk@2,0:b' 22:06:28 dev_path=/pci@0,0/pci103c,870c@17/disk@2,0:b 22:06:35 spectype=blk type=minor 22:06:47 dev_link=/dev/dsk/c1t2d0s1 22:06:55 dev_path=/pci@0,0/pci103c,870c@17/disk@2,0:b,raw 22:07:03 spectype=chr type=minor 22:07:11 dev_link=/dev/rdsk/c1t2d0s1 22:23:59 pilonsi: BTW, could you check that /etc/path_to_inst in both datasets have that path '/pci@0,0/pci103c,870c@17/disk@2,0' ? 22:24:57 pilonsi: Also I would suggest to recreate '/platform/i86pc/amd64/boot_archive' in the failing dataset 22:25:14 pilonsi: but save a copy before. 22:32:28 In both /etc/path_to_inst I get the same: 22:32:28 "/pci@0,0/pci103c,870c@17/disk@2,0" 1 "sd" 22:33:19 Why do you think I should recreate the the boot archive in the dataset that was failing? 22:33:25 Even if it's already booting ok? 22:33:31 (And how could I do it?) 22:39:41 `bootadm update-archive` creates/updates the archive, but if it's outdated on boot we recreate it and reboot again (if we get far enough) 22:48:20 I didn't know about the bootadm tool.. What is the boot archive? Is it a Solaris/illumos specific thing? 22:51:58 it's (just about) what linux calls an initrd 23:00:46 Thanks, I figured.. There is still some illumos terminology I have to get used to 23:23:24 jbk: Thank you 23:24:59 ? 23:25:06 what did i do? :) 23:44:46 thank for the answer to setup a slog for all SSD device :) 23:48:53 ahh ok