On 18/02/2022 04:08, John-Mark Gurney wrote:
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.
Thank you very much for looking into this.
I'll try to draw Kirk's attention to this issue (he is also in this thread, but
a different sub-thread).
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.
--
Andriy Gapon
