NetBSD/sbin/resize_ffs/resize_ffs.8

.\"     $NetBSD: resize_ffs.8,v 1.3 2003/03/10 09:23:23 wiz Exp $
.\"
.\" As its sole author, I explicitly place this man page in the public
.\" domain.  Anyone may use it in any way for any purpose (though I would
.\" appreciate credit where it is due).
.\"
.\" /~\ The ASCII                           der Mouse
.\" \ / Ribbon Campaign
.\"  X  Against HTML               mouse@rodents.montreal.qc.ca
.\" / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
.\"
.Dd February 20, 2003
.Dt RESIZE_FFS 8
.Sh NAME
.Nm resize_ffs
.Nd resize an on-disk file system
.Sh SYNOPSIS
.Nm
.Ar file-system-raw-device
.Ar newsize
.Sh DESCRIPTION
.Nm
resizes a file system on disk.
.Ar file-system-raw-device
is the name of the raw disk device where the file system resides;
.Ar newsize
is the desired new file system size, in sectors.
(Sectors are almost always 512 bytes, and
.Nm
can both grow and shrink file systems.
When growing, the disk device
must of course be large enough to contain the new file system;
.Nm
simply extends the file system data structures into the new space.
When shrinking,
.Nm
assumes this.
It will not work correctly for file systems with other sector sizes.)
.Nm
has to copy anything that currently resides in the space being shrunk
away; there must be enough space free on the file system for this to
succeed.
If there isn't,
.Nm
will complain and exit; when this happens, it attempts to always leave
the file system in a consistent state, but it is probably a good idea to
check the file system with
.Xr fsck 8 .
.Sh WARNING
.Nm
should still be considered experimental.  It still needs to be validated
with a rigorous regression test suite.
.Em Interrupting
.Nm
.Em "may leave your file system in an inconsistent state and require a"
.Em "restore from backup."
It attempts to write in the proper order to avoid problems, but as it is
still considered experimental, you should take great care when using it.
.Pp
When
.Nm
is applied to a consistent file system, it should always produce a
consistent file system; if the file system is not consistent to start
with,
.Nm
may misbehave, anything from dumping core to completely curdling the
data.
It's probably wise to
.Xr fsck 8
the file system before and after, just to be safe.
.\" Remove this when (if) fsck gets fixed.
.Pp
There is a bug somewhere in fsck; it does not check certain data
structures enough.
A past version of this program had a bug that produced corrupted
rotation layout summary tables, which would panic the kernel.
This bug is believed fixed, and there are currently no
known bugs in the program.
However, you should be aware that just
because fsck is happy with the file system does not mean it is intact.
.Sh EXAMPLES
.Ic resize_ffs Cm /dev/rsd1e 29574
.Sh SEE ALSO
.Xr fs 5 ,
.Xr fsck 8 ,
.Xr newfs 8
.Sh HISTORY
The
.Nm
command first appeared in
.Nx 2.0 .
.Sh AUTHORS
.An der Mouse
.Aq mouse@rodents.montreal.qc.ca
.Pp
A big bug-finding kudos goes to John Kohl for finding the rotational
layout bug referred to in the
.Sx WARNING
section above.
.Sh BUGS
Has not been tested and probably won't work on opposite-endian file
systems.
.Pp
Can fail to shrink a file system when there actually is enough space,
because it does not distinguish between a block allocated as a block
and a block fully occupied by two or more frags.
This is unlikely to
occur in practice; except for pathological cases, it can happen only
when the new size is extremely close to the minimum possible.
.Pp
Has no intelligence whatever when it comes to allocating blocks to copy
data into when shrinking.