resize_ffs(8) [netbsd man page]
RESIZE_FFS(8) BSD System Manager's Manual RESIZE_FFS(8) NAME
resize_ffs -- resize a file system on disk or in a file SYNOPSIS
resize_ffs [-y] [-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 isn't, 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: -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 speci- fication or the disklabel. Mostly used to shrink file systems. -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 consis- tent to start with, resize_ffs may misbehave, anything from dumping core to completely curdling the data. It's 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. Doesn't currently support shrinking FFSv2 file systems. BSD
January 4, 2011 BSD
Check Out this Related Man Page
WAPBL(4) BSD Kernel Interfaces Manual WAPBL(4) NAME
WAPBL -- Write Ahead Physical Block Logging file system journaling SYNOPSIS
options WAPBL options WAPBL_DEBUG DESCRIPTION
The WAPBL driver provides meta-data journaling for file systems. In particular, it is used with the fast file system (FFS) to provide rapid file system consistency checking after a system outage. It also provides better general-use performance over regular FFS. WAPBL currently maintains its journal in one of two locations: - After the file system The journal is placed in the same partition as the file system, but between the file system and the end of the partition. - Within the file system The journal is allocated as a special contiguous file within the file system. The journal file is not visible via normal file system access. A new journal is created automatically when a file system is mounted via mount(8) with the -o log option. If no journal size has been speci- fied with tunefs(8), then the size of the journal will be based on 1MB of journal per 1GB of file system, to a maximum journal size of 64MB. If there is adequate space between the end of the file system and the end of the partition, then unless the journal size has been specified with tunefs(8) then the journal will be created after the file system. To obtain space between the file system and the end of the partition the size of the partition can be adjusted using disklabel(8). Care must be taken not to damage existing data on existing partitions, but this method will work well if, for example, a swap partition can be shrunk in order to accommodate the journal after the file system on a partition before the swap partition. For a new file system, newfs -s -64m wd0a can be used to leave space for a 64MB journal at the end of /dev/wd0a. To specify the size of the journal within the file system tunefs(8) can be used as follows: tunefs -l 64m wd0a to indicate that a journal of size 64MB on the file system on /dev/wd0a should be created the next time that file system is mounted. This must be done before the file system is mounted with the ``-o log'' option. For existing file systems and general use, however, simply using mount -o log /dev/wd0a /mnt will be sufficient to create an appropriate journal within the file system. Running tunefs -l 0 wd0a will schedule the log for removal on the next read-write mount, and running tunefs -l 0 wd0a followed by mount -o log /dev/wd0a /mnt will remove the log and then re-create it with the default size. This method can also be used to grow or shrink the size of the journal. With the journal, fsck(8) is no longer required at system boot. If the system has been shutdown in an unclean fashion then the journal will be replayed when the file system is mounted. fsck(8) can still be used to force a consistency check of the file system should that be desired. For kernel developers, the compile time option WAPBL_DEBUG turns on debugging. SEE ALSO
config(1), fsck(8), mount(8), newfs(8), umount(8) HISTORY
WAPBL was originally written by Darrin B. Jewell while at Wasabi Systems Inc. Wasabi Systems contributed the code to NetBSD and was inte- grated by Simon Burge, Antti Kantee, Andy Doran, and Greg Oster. WAPBL first appeared in NetBSD 5.0. CAVEATS
Older releases of the system, and other systems that support the UFS format should only access WAPBL file systems in read-only mode. Addi- tionally, the fsck(8) command from such systems should not be run against WAPBL file systems. Failure to observe these guidelines may damage the file system. WAPBL requires the super block to be in the UFS2 format. The super block format can be checked using the -s option with dumpfs(8), and older FFSv1 file systems will need to be updated to the newer super block layout with the -c option to fsck_ffs(8). fsync(2) causes all outstanding metadata transactions to be committed to disk, introducing additional latency. This can have an impact on database software and other software that calls fsync(2) often. In-file system log allocation should be done on a relatively quiet file system. The error path for log allocation failures could result in a ``dangling inode'' issue, requiring an fsck(8) to fix. BSD
July 26, 2012 BSD