Re: resize_ffs isn't resizing

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Wed, 10 Dec 2025, Michael van Elst wrote:

> netbsd%precedence.co.uk@localhost (Stephen Borrill) writes:
>
> >     262208  60563392      2  GPT part - NetBSD FFSv1/FFSv2
> ...
> >     262208  80563392      2  GPT part - NetBSD FFSv1/FFSv2
> ...
> > Now to resize the filesystem:
> > # resize_ffs -vy /dev/rdk1
> > Growing fs from 15140848 blocks to 20140848 blocks
>
> > Why 20140848, not 80563392? Even if I specify 80563392 with -s, it still only grows to 20140848.
>
>
> I would wonder about the 'from' value.
>
> before 60563392 / 4 = 15140848
>
> after  80563392 / 4 = 20140848
>
> This is the number of filesystem 'fragments' and fits
> the resize operation.
>
>
> > dumpfs concurs:
> > ncg     217     size    20140848        blocks  19524526
> > bsize   16384   shift   14      mask    0xffffc000
> > fsize   2048    shift   11      mask    0xfffff800
>
> 'size' and 'blocks' are measured in terms of fragments.

OK, I'm happy with the explanation of size from dumpfs being multiples of 
fsize not sectors, but not the rest. The problem is that the term 'blocks' 
is used inconsistently. In dmesg and df, it means sectors. In resize_ffs 
and dumpfs it means 'fragments'.

resize_ffs(8) says that -s is in sectors ("The size is given 
as the count of disk sectors, usually 512 bytes". It avoids the word 
blocks). It's therefore particularly confusing that it appears to switch 
between meanings when run with -v:

# resize_ffs -vy -s 80563392 /dev/rdk1
Growing fs from 15140848 blocks to 20140848 blocks

I will look at improving the output of resize_ffs -v.

> > I don't gain any free space:
> > Filesystem      1K-blocks         Used        Avail %Cap Mounted on
> > root_device      29355772     29326868     -1438884 105% /
>
> You cannot resize a mounted filesystem. While resize_ffs writes
> bits to the disk, the filesystem still works with cached values.

I expected this, but assumed that doing an explicit read/write mount 
afterwards would update it.

This is all from me helping out a colleague who was following instructions 
I'd written which were explicitly for non-root filesystems (i.e. the 
filesystem wasn't mounted at all, not even read-only, so nothing was 
cached). I've since improved the documentation so he doesn't make the same 
mistake next time :-)

> > And at a reboot, if I run resize_ffs again it claims to be growing from 15140848 to 20140848 again, so appears to have done nothing.
>
> Looks like the filesystem was mounted read-write and at umount
> time, wrote back the cached superblock. If your are lucky, it
> did just undo the resize.
>
> The /etc/rc.d/resize_root script only avoids disaster because it
> resizes the still read-only mounted filesystem and then reboots
> immediately.

Yes, you're right. Him doing mount -a and then umounting messed up the 
superblock. This was spotted by subsequent fscks.

> If you are sure that the filesystem was still read-only, I could
> imagine that there is an issue with cache flushing of the virtual
> disk. Maybe doing a 'dkctl xbd0 synccache' makes a difference.

dkctl: /dev/rxbd0: synccache: Operation not supported

--
Stephen