Andriy Gapon wrote this message on Tue, Feb 15, 2022 at 08:44 +0200: > On 15/02/2022 01:17, John-Mark Gurney wrote: > > Andriy Gapon wrote this message on Mon, Feb 07, 2022 at 14:15 +0200: > >> I've got a problem where fsck behaves differently from my expectations. > >> The problem happens with a filesystem on a GELI encrypted ZVOL. > >> The volume has 4K block size and that's the GELI's sector size as well. > >> FreeBSD is stable/13 from mid January. > > > > Did you put a ffs filesystem that was formatted on a 512 byte sector disk > > onto this geli device? > > As far as I can recall, no. I created it with newsfs on the geli device.
Looks like it's a bug in newfs, as I just reproduced this myself: fsbtodb int32_t 0x00000003 and manually specifying a sector size of 4096 to newfs does not fix the issue. This is the issue: https://cgit.freebsd.org/src/blame/sbin/newfs/newfs.c#n399 It changes the sectorsize back down to 512 from whatever it should be, which means that the calculation in mkfs.c becomes off. I'd file a bug report and get someone who knows FFS to look at it. I tried to change mkfs.c to use realsectorsize isntead, so fsbtodb is set to 0, but then it break ffsinfo, because it's calculations are likely wrong. > > fsck calculates the sector size via (/sbin/fsck_ffs/setup.c): > > dev_bsize = sblock.fs_fsize / fsbtodb(&sblock, 1); > > > > and fsbtodb: > > ../../sys/ufs/ffs/fs.h:#define fsbtodb(fs, b) ((daddr_t)(b) << > > (fs)->fs_fsbtodb) > > > >> fsize 4096 shift 12 mask 0xfffff000 > >> frag 8 shift 3 fsbtodb 3 > > > > fsize / (1 << 3) == 4096 / 8 == 512. > > > > so, likely updating fsbtodb to be 0 instead of 3 would fix this. I'm not > > sure how to do this though, as tunefs and fsdb don't seem to have options > > to do this, and likely you'll want to update all the superblocks w/ this > > new value. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
