01:03:39 does it not? 01:27:51 rtprio: does it not what? 02:03:48 hm 02:04:04 I was wondering why updating from 14.3 --> 15.0 pf was blocking packets 02:04:22 in 14.3 pass out was default in pf, if you blocked in you had an implicit pass out 02:04:28 but in 15.0 this is gone, and you must explicitly pass out 02:04:36 interesting... 03:54:19 adonis: you cant smartctl -a /dev/gpt/id/${uuid}? 04:00:25 rtprio, What? /dev/gpt/id/something? Does that exist? Does something enable it? 04:54:03 rwp: i thought it could be 04:55:11 /dev/gptid/832f9f02-92ec-11ed-a294-589cfc0428ea hrm, but that's a partition 04:58:39 why not prevent the identifiers from changing? 05:17:00 rtprio: smartctl -a /dev/gpt/ doesn't work. How do I prevent the identifiers from changing? 05:18:02 well, let's back up; what drive is it? 05:18:26 I have multiple drives in a zfs pool (3.5 spinning disks). I assigned labels to them. 05:19:04 I'm not sure how or why, but sometimes the drives identifier ada0, ada1, gets shuffled around and ada0 might not exist anymore. 05:19:13 which breaks my smartd.conf 05:19:32 does this happen randomly on boot or ... 05:20:04 yes its on reboot/shutdown/startup of system. 05:20:16 shutdown+startup 05:20:48 its important to note that freebsd is running a vm, and the disks are passed through to it. 05:20:56 uh, something causes it 05:20:58 running *as a vm 05:20:59 ok, there it is 05:27:01 that is an ... unusual way to run ZFS 05:27:28 :).. I used to run on baremetal but since I have a lot of cores on my zfs machine I turned into a vm host 05:28:01 inside the host is my freebsd vm with zfs pool (pass-through disks).. 05:29:41 Unfortunately modern kernels (both *BSD and Linux) order /dev/da? drives at boot time and rather dynamically and prone to race conditions. As far as I know it is not possible to force this to be persistent. Other than UUID labels. 05:30:03 there _used_ to be a kernel option to make them more static 05:30:07 but i can't seem to find it again 05:30:09 I just haven't run into a case myself where it mattered for my smartd.conf configuration which drive was which drive. 05:31:06 My systems all have two drives or eight drives or whatever but they are all equiv and so it doesn't matter if they are re-ordered at boot time or not. And for ZFS I am using GPT partitions so those are persistent but those are not used by smartd. 05:31:28 rwp: are you just doing DEVICESCAN in your smartd.conf? 05:31:45 Nope. I list them out. Example: /dev/da0 -a -I 190 -I 194 -o on -S on -s (S/../../[1-6]/03) -m root 05:32:16 And so on 1, 2, 3, ... with different hours to run self tests but it doesn't matter if they have moved around as long as all of them get a self test each night. 05:32:34 I skew the hours so that they don't all run at the same time. 05:32:37 rwp: I'm doing the same, the issue is on reboot's etc, that da0 may no longer exist because it became da1. So a group of disks da0-da4 referenced in my smartd.conf becomes da1-da5 05:33:08 At reboot I have never seen 0 be vacant. The kernel will always allocate device ids starting with 0 and on through N. 05:33:13 here's an idea, don't reboot 05:34:13 rwp: Ok, I'm probably wrong.. then what happen is da0 becomes ada0.. 05:34:18 happens* 05:34:50 what the heck is your virtualization doing 05:34:50 I obviously have to test what scenario causes this issue better lol, but that’s the gist yea. 05:35:45 da0 is for SCSI, SAS, USB devices. ada is for SATA devices. If you have ada then you have a SATA device. 05:36:17 A /dev/daX device will not become a /dev/adaX device. It will just always be a /dev/adaX device. 05:36:49 My example above is for a system with SAS disks. And you were talking about /dev/daX so I went there for the example. 05:36:57 hmm ok, I have be to be wrong then as to how the identifiers are changing. 05:37:16 well is just the number changing or what 05:37:31 let me reboot now. 05:37:34 Usually it is just the number changing. 05:38:15 ok, I can't lol. 05:38:47 And especially if two SATA devices are on different SATA controllers such as when two are on the primary motherboard bridge and the motherboard has six more on a secondary controller. There appears to be a race condition enumerating them and those are what I see changing most often. 05:39:15 wait 05:39:31 I have a group of disks on SCSI yes, and another group on SATA 05:39:32 why not just run smart on the host when the vm goes down 05:39:36 this just seems... backwards 05:40:58 rtprio: why would I run it on the host for the disks that are passed through. Once passed through they are no longer even seen by the host. 05:44:40 rwp: regarding the starting from 0, I'm looking at my ada disks right now and they are starting from ada2 05:45:12 I did some research and apparently kern.geom.label.disk_ident.enable=1 will enable /dev/diskid/* but none of my systems have it enabled. Do newer installed systems enable it by default? 05:46:04 rwp: that’s from a 6-port sata controller with only disks connected 05:46:15 4* disks connected 05:47:25 Interesting. I haven't seen that myself. I am going to enable kern.geom.label.disk_ident.enable=1 on one of my test systems and see what happens. 05:48:24 rwp: ok, no, I'm wrong again, sorry. I do see I have a ada0 and ada1, those just don't show via 'camcontrol devlist' 05:48:31 I am curious. If you run "camcontrol devlist" do the passX numbers also start at 2? 05:49:06 Oh, okay, whew! Because that preserves what I thought must happen. 05:49:25 So my vm has ada0 and ada1 which are not pass through disks but logical disks that I created in the vm host itself and gave to freebsd. 05:49:34 logical virtual disks 05:50:11 ada2-ada5 are sata disks from the 6port sata controller I'm passing through 05:51:55 I'm looking at the history of my smartd.conf.. and yea I see it used to reference ada0 and ada1 as some of my pool disks.. 05:52:22 I am not quite tracking. Your FreeBSD system with the /dev/adaX starting at 2 is a virtual machine? And the hosting system is a FreeBSD system with /dev/adaX starting at 0? Wish I had a diagram... 05:53:39 I'll explain. My FreeBSD system is a VM. It has two disks (virtual disks) given to it from the vm host that show up as adaX disks. It also has another group of 8 disks that are passed through completely, a group of 4 disks on a SCSI controller and a group of 4 on a SATA controller. 05:55:00 the virtual disks are simply for OS storage and a swap partition. The 8 passed through disks are for the zfs pool. The 8 passed through disks are what I am monitoring in smartd.conf. 05:57:14 I can see in my smartd.conf history that at some point the disks monitored were ada0-ada3, da0-da3. But then that broke as it seemed the sata disks changed from being ada0-ada3 to ada2-ada5. 05:57:15 On the system I enabled that kernel option and rebooted has an internal mmcsd nand flash storage device but I am not using it at all. That device then showed up in /dev/diskid/DISK-A2AE2A17 and all partitions on it. But that device is not smart capable. None of the SATA disks on that system show up in that directory. 05:57:58 I imagine that at early boot time all devices are in /dev/diskid/* but then as they are consumed and mounted the kernel removes all other devices, as it does, to prevent then from being accessed. 05:59:55 And so the result on my test system is that only the unused device is left in /dev/diskid/* so even if that "works" it is not useful for smart access. 06:02:07 rwp: how does FreeBSD determine that my two vm disks should stay at ada0 and ada1 (my pool disks ada2-ada5) instead of flipping to ada4, ada5 (my pool disks ada0-ada3)? 06:02:21 on a reboot 06:03:56 is it just a matter of which disks it detects first? 06:03:59 I don't know. It's outside my expertise. But I would have said they are not guaranteed to be stable. They might change on reboot. And that's the issue. 06:04:15 good morning 06:04:20 yup that the issue :D 06:04:42 Not to ghost you but I need to drop afk immediately for a bit... 06:04:56 rwp: no prob! 06:05:22 i tried wayland but with my old hardware and legacy driver, it seemed like it is better to stick with X 06:11:24 I feel like opening a ticket on smartmontools. Would be nice if it just supported identifying disks by /dev/gpt/