14:06:10 <jbk> this is a bit into the weeds of UFS, but anyone know (or know of an easy way to tell) if changing the underlying size of the 'device' (in this case it's just a file) from < 512MiB to > 512MiB changes some internal sizing that'd result in noticably less free space for the exact same set of files?
14:11:26 <jbk> we build an image by taking the size of the files going into it + 20%, but recently, mounting it, df shows almost 0% free and I noticed that the total size is a hair over 512MiB... just seemed suspicious
14:19:40 <rmustacc> Maybe check what fragsize is?
14:20:53 <rmustacc> And probably some of the other tuning defaults of newfs like the bytes per inode, etc.
15:54:04 <sommerfeld> jbk: also the "free" parameter which by default hides up to 10% of the filesystem capacity.
15:57:48 <sommerfeld> jbk: the tunables are perhaps better documented in mkfs_ufs(8); look at newfs -v output at different sizes.
19:15:19 <jbk> uugh.. i really wish we didn't use semaphores in all the bio*() code
19:18:21 <jbk> have a BMC that for some reason w/ the virtual CDROM, INQUIRY appears to succeed, but GET CAPACITY apparently hangs during attach, so we remain blocked forever in sema_p() in biowait()
19:18:34 <jbk> while the entire device tree is locked
19:19:33 <richlowe> it is hard to reason about devices that, uh, are broken as hell?
19:22:09 <jbk> we're going to try it tomorrow, but I suspect fbsd and linux probably deal with it fine... my guess is either we're doing something wrong that real hardware normally overlooks but whatever virtualized USB running on the BMC does not like, or we're stricter in somewhat no one else is which is tripping up the BMC
19:22:34 <jbk> just it makes it so much harder to diagnose because you can't timeout
19:23:08 <jbk> (also, it appears to happen after the firmware was upgraded, which sadly doesn't appear possible to downgrade)
19:23:53 <hadfl> when in doubt, always blame the BMC
19:24:01 <jbk> it is the safe assumption :)
19:25:09 <jbk> though annoyingly, it apparently also impacts _physical_ USB storage devices connected to the system as well
19:25:23 <jbk> though I haven't had a chance to confirm if it's the exact same pathology
19:25:32 <jbk> just 'it won't boot'
19:31:50 <richlowe> is that reported speech?  because it's always good with I/O stuff to wait out "won't boot" if you're diagnosing it
19:31:56 <richlowe> sometimes it boots in ~infinite time