NAME
resize_ffs —
resize a file system on
disk or in a file
SYNOPSIS
resize_ffs |
[-cpvy]
[-s size]
special |
DESCRIPTION
resize_ffs resizes a file system.
special is the name of the raw disk device or file where
the file system resides.
resize_ffs can both grow and shrink
file systems. When growing, the disk device must of course be large enough to
contain the new file system;
resize_ffs simply extends the
file system data structures into the new space. When shrinking,
resize_ffs assumes this.
resize_ffs 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 is
not,
resize_ffs 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
fsck(8).
If no
-s option is provided,
resize_ffs will
grow the file system to the underlying device size which is determined from
special.
The options are as follows:
-
-
- -c
- Check to see if the new size would change the file system.
No changes will be made to the file system.
-
-
- -p
- Display a progress meter during the resize process.
-
-
- -s
- Specify the file system size to which the file system
should be resized. 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. To see the exact value, have a look at the disk specification or
the disklabel. Mostly used to shrink file systems.
-
-
- -v
- Be more verbose.
-
-
- -y
- Disable sanity questions made by
resize_ffs.
WARNING
Interrupting resize_ffs may
leave your file system in an inconsistent state and require a
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.
When
resize_ffs 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,
resize_ffs may misbehave, anything
from dumping core to completely curdling the data. It is probably wise to
fsck(8) the file system before and
after, just to be safe. You should be aware that just because
fsck(8) is happy with the file
system does not mean it is intact.
EXIT STATUS
resize_ffs exits with 0 on success. Any major problems will
cause
resize_ffs to exit with the non-zero
exit(3) codes, so as to alert any
invoking program or script that human intervention is required.
EXAMPLES
resize_ffs
/dev/vg00/rlv1
will enlarge the file system on the Logical Volume
/dev/vg00/lv1 from Volume Group vg00 to the current device
size.
SEE ALSO
fs(5),
fsck(8),
newfs(8)
HISTORY
The
resize_ffs command first appeared in
NetBSD 2.0.
AUTHORS
der Mouse ⟨mouse@rodents.montreal.qc.ca⟩
(primary author)
Jeff Rizzo ⟨riz@NetBSD.org⟩ (Byteswapped
file system and UFS2 support)
A big bug-finding kudos goes to John Kohl for finding the rotational layout bug
referred to in the
WARNING section above.
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.
Has no intelligence whatever when it comes to allocating blocks to copy data
into when shrinking.
Does not currently support shrinking FFSv2 file systems.