RESIZE_FFS(8) | System Manager's Manual | RESIZE_FFS(8)

# 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 a significant rotational layout bug.

# 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.

October 1, 2017 | NetBSD 11.99