01:11:11 <tozhu> one question regarding to crucible on Oxide sled node, according the docs, there is 10 pool created on a physical sled on the 10 SSD, it means there is 1 SSD created a pool , is it true? I’m going to find a way to run PostgreSQL  with best performance on crucible, and want to learn how to setup crucible with best performance, any one could help?  a big thanks, andyf rmustacc jclulow , could give me any hint, thank you :-)
02:34:34 <jbk> sommerfeld: socket_vop_getattr() has a better (though still not great) way of choosing inode values FWIW
02:35:08 <jbk> (it was embarassingly worse -- 2^16 unique values -- before that)
20:36:48 <richlowe> I've asked this before, but it it came up in my mind again
20:37:07 <richlowe> is _anyone_ investigating why 'zfs send/recv' seem to ignore the large blockno feature, and create invalidly big blockids?
20:37:33 <richlowe> when I brought it up initially, people mentioned they knew about it, which I took to mean someone... cared
20:38:42 <richlowe> the symptoms are things like `warning: zfs bug: bn be2 > dn_maxblkid be1`
20:39:09 <richlowe> it's in my use case precisely always 2 blocks over
20:39:13 <richlowe> I'm not sure if that's definite
20:39:29 <richlowe> (you can see the code/warning in loader's libsa/zfs/zfsimpl)
20:40:05 <tsoome> https://www.illumos.org/issues/5905 -- I did create that check in loader for this one
20:40:06 <fenix> → BUG 5905: wrong dn_maxblkid on dnode received to large_block dataset (New)
20:40:24 <richlowe> I am very unfamiliar with ZFS, so I can't really get further without devoting all my time to learning ZFS-isms
20:40:37 <richlowe> which I'm hoping people who, like, sell things based on ZFS already know.
20:40:59 <richlowe> tsoome: thanks, that's a reference I don't think I had
20:41:14 <tsoome> but I havent really had spent much time digging it:(
20:43:22 <tsoome> I havent seen it doing any harm, but I have only seen it related with boot_archive and thats something we can easily regenerate:)
20:45:37 <richlowe> Yes, I see it on ARM with every new image build
20:46:04 <richlowe> because we build the generic filesystem image, and then send/recv it onto the platform-specific disk
20:46:24 <richlowe> at which point the boot_archive grows two blocks bigger than is possible 
20:46:59 <richlowe> but since people were talking about send/recv mysteries on the list, I hoped I could interest someone who already knows things 
20:49:25 <tsoome> well, that did not really happen when I did create the issue:D