tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: resizing the root file system



> Are there any precautions I need to take after resizing the root fs?
> I don't see /etc/rc.d/resize_root taking any.

Well, you need to either mount -o reload or reboot.

> I moved the other partitions away, booted single user, enlarged the
> partition, fsck'd / and did resize_ffs.  I did another fsck / after
> that, which showed no errors, but (as expected) more free blocks than
> before.  I then went multi-user but suddenly the additional free
> space is gone

If you'd checked with df instead of fsck, you probably would have never
seen it to begin with.

resize_ffs works on the disk device, not on the filesystem.  After a
resize_ffs of a mounted filesystem, you really need to discard all
in-core state for that filesystem, meaning mount -o remount or a reboot
*without*, in either case, syncing any state to disk.  (If the
filesystem is mounted read-only, it normally won't sync anything
anyway, but I'd still do a pull-the-power-cord reset instead of a
reboot(8) just to be sure.)

I'd fsck again after the reboot, but that's more because I'm paranoid
about such things than because it's actually needed.

> dumpfs -as shows the primary sb reflects the old and the backups
> reflect the new size.

The primary got written from the copy cached in core; the backups
didn't.

You can _probably_ recover the space by booting single-user and using
-b to fsck_ffs to have it use one of the backup superblocks...and then
rebooting without sync after fsck finishes.  Or you can use a normal
fsck, let it set the size back down, and then resize it again when
you're done.

> This is all on -6 in case it matters.  Please don't tell me I need to
> update, that's the reason I need to enlarge /.

Heh.  I wrote fsresize (it was renamed when it was imported into
NetBSD) back in the NetBSD 1.* days.

> Another question is why I needed to /boot/ into single user.  I
> /went/ single user but couldn't mount -u -r / from there (ENOTSUP).

As long as you are running with the root filesystem mounted read-only,
it doesn't much matter how you got to that state.  But I _think_ you
can't convert a read/write mount to read-only without an unmount, which
for the root filesystem means a reboot.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index