108 lines
3.5 KiB
Groff
108 lines
3.5 KiB
Groff
.\" $NetBSD: resize_ffs.8,v 1.2 2003/02/23 00:26:02 lukem 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 filesystem
|
|
.Sh SYNOPSIS
|
|
.Nm
|
|
.Ar filesystem-raw-device
|
|
.Ar newsize
|
|
.Sh DESCRIPTION
|
|
.Nm
|
|
resizes a filesystem on disk.
|
|
.Ar filesystem
|
|
is the name of the raw disk device where the filesystem resides;
|
|
.Ar newsize
|
|
is the desired new filesystem size, in sectors. (Sectors are almost
|
|
always 512 bytes, and
|
|
.Nm
|
|
can both grow and shrink filesystems. When growing, the disk device
|
|
must of course be large enough to contain the new filesystem;
|
|
.Nm
|
|
simply extends the filesystem data structures into the new space. When
|
|
shrinking,
|
|
.Nm
|
|
assumes this. It will not work correctly for filesystems 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 filesystem for this to
|
|
succeed. If there isn't,
|
|
.Nm
|
|
will complain and exit; when this happens, it attempts to always leave
|
|
the filesystem in a consistent state, but it is probably a good idea to
|
|
check the filesystem with
|
|
.Xr fsck 8 .
|
|
.Pp
|
|
.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 filesystem, it should always produce a
|
|
consistent filesystem; if the filesystem 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 filesystem 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 filesystem does not mean it is intact.
|
|
.Sh EXAMPLES
|
|
.Nm
|
|
.Li /dev/rsd1e 29574
|
|
.Sh SEE ALSO
|
|
.Xr fs 5 ,
|
|
.Xr newfs 8 ,
|
|
.Xr fsck 8
|
|
.Sh AUTHOR
|
|
.Li der Mouse <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 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 filesystem 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.
|
|
.Sh HISTORY
|
|
The
|
|
.Nm
|
|
command first appeared in
|
|
.Nx 2.0 .
|