NetBSD/sbin/resize_ffs/resize_ffs.8

147 lines
4.0 KiB
Groff
Raw Normal View History

.\" $NetBSD: resize_ffs.8,v 1.16 2015/04/06 22:44:04 jmcneill Exp $
2003-02-23 03:26:02 +03:00
.\"
.\" 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
2003-02-23 03:26:02 +03:00
.\"
.Dd April 6, 2015
.Dt RESIZE_FFS 8
2010-12-20 02:22:46 +03:00
.Os
.Sh NAME
.Nm resize_ffs
.Nd resize a file system on disk or in a file
.Sh SYNOPSIS
.Nm
.Op Fl cpvy
.Op Fl s Ar size
.Ar special
.Sh DESCRIPTION
.Nm
resizes a file system.
.Ar special
is the name of the raw disk device or file where the file system resides.
.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.
.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 .
.Pp
2010-10-31 14:39:46 +03:00
If no
.Fl s
option is provided,
.Nm
will grow the file system to the underlying device size which is
determined from
.Ar special .
.Pp
2010-10-31 14:39:46 +03:00
The options are as follows:
.Bl -tag -width indent
.It Fl c
Check to see if the new size would change the file system.
No changes will be made to the file system.
.It Fl p
Display a progress meter during the resize process.
2010-10-31 14:39:46 +03:00
.It Fl s
Specify the file system size to which the file system should be
resized.
2011-08-28 21:15:16 +04:00
The size is given as the count of disk sectors, usually 512 bytes.
It will not work correctly for file systems with other sector sizes.
2011-08-28 21:15:16 +04:00
To see the
exact value, have a look at the disk specification or the disklabel.
2010-10-31 14:39:46 +03:00
Mostly used to shrink file systems.
.It Fl v
Be more verbose.
.It Fl y
2010-10-31 14:39:46 +03:00
Disable sanity questions made by
.Nm .
.El
.Sh WARNING
.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.
You should be aware that just because
2010-10-31 14:39:46 +03:00
.Xr fsck 8
is happy with the file system does not mean it is intact.
.Sh EXIT STATUS
.Nm
2010-10-31 14:39:46 +03:00
exits with 0 on success.
Any major problems will cause
.Nm
to exit with the non-zero
.Xr exit 3
codes, so as to alert any invoking program or script that human
intervention is required.
.Sh EXAMPLES
.Dl resize_ffs Cm /dev/vg00/rlv1
2010-10-31 14:39:46 +03:00
.Pp
will enlarge the file system on the Logical Volume
.Pa /dev/vg00/lv1
2010-10-31 14:39:46 +03:00
from Volume Group vg00 to the current device size.
.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
(primary author)
.An Jeff Rizzo
.Aq riz@NetBSD.org
(Byteswapped file system and UFS2 support)
.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
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.
.Pp
Doesn't currently support shrinking FFSv2 file systems.