Re: resize_ffs isn't resizing

[mlelstv%serpens.de@localhost (Michael van Elst)]

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.


>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.

>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.

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.