Date: Mon, 14 Feb 2022 15:17:58 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-stable List <stable@FreeBSD.org>, freebsd-fs <fs@FreeBSD.org>, "freebsd-geom@FreeBSD.org" <geom@freebsd.org> Subject: Re: fsck -C -p: NO WRITE ACCESS Message-ID: <20220214231758.GD97875@funkthat.com> In-Reply-To: <346d021f-b737-f41a-883f-e821389c4431@FreeBSD.org> References: <346d021f-b737-f41a-883f-e821389c4431@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220214231758.GD97875>