1.\" $NetBSD: resize_ffs.8,v 1.3 2003/03/10 09:23:23 wiz Exp $ 2.\" 3.\" As its sole author, I explicitly place this man page in the public 4.\" domain. Anyone may use it in any way for any purpose (though I would 5.\" appreciate credit where it is due). 6.\" 7.\" /~\ The ASCII der Mouse 8.\" \ / Ribbon Campaign 9.\" X Against HTML mouse@rodents.montreal.qc.ca 10.\" / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B 11.\" 12.Dd February 20, 2003 13.Dt RESIZE_FFS 8 14.Sh NAME 15.Nm resize_ffs 16.Nd resize an on-disk file system 17.Sh SYNOPSIS 18.Nm 19.Ar file-system-raw-device 20.Ar newsize 21.Sh DESCRIPTION 22.Nm 23resizes a file system on disk. 24.Ar file-system-raw-device 25is the name of the raw disk device where the file system resides; 26.Ar newsize 27is the desired new file system size, in sectors. 28(Sectors are almost always 512 bytes, and 29.Nm 30can both grow and shrink file systems. 31When growing, the disk device 32must of course be large enough to contain the new file system; 33.Nm 34simply extends the file system data structures into the new space. 35When shrinking, 36.Nm 37assumes this. 38It will not work correctly for file systems with other sector sizes.) 39.Nm 40has to copy anything that currently resides in the space being shrunk 41away; there must be enough space free on the file system for this to 42succeed. 43If there isn't, 44.Nm 45will complain and exit; when this happens, it attempts to always leave 46the file system in a consistent state, but it is probably a good idea to 47check the file system with 48.Xr fsck 8 . 49.Sh WARNING 50.Nm 51should still be considered experimental. It still needs to be validated 52with a rigorous regression test suite. 53.Em Interrupting 54.Nm 55.Em "may leave your file system in an inconsistent state and require a" 56.Em "restore from backup." 57It attempts to write in the proper order to avoid problems, but as it is 58still considered experimental, you should take great care when using it. 59.Pp 60When 61.Nm 62is applied to a consistent file system, it should always produce a 63consistent file system; if the file system is not consistent to start 64with, 65.Nm 66may misbehave, anything from dumping core to completely curdling the 67data. 68It's probably wise to 69.Xr fsck 8 70the file system before and after, just to be safe. 71.\" Remove this when (if) fsck gets fixed. 72.Pp 73There is a bug somewhere in fsck; it does not check certain data 74structures enough. 75A past version of this program had a bug that produced corrupted 76rotation layout summary tables, which would panic the kernel. 77This bug is believed fixed, and there are currently no 78known bugs in the program. 79However, you should be aware that just 80because fsck is happy with the file system does not mean it is intact. 81.Sh EXAMPLES 82.Ic resize_ffs Cm /dev/rsd1e 29574 83.Sh SEE ALSO 84.Xr fs 5 , 85.Xr fsck 8 , 86.Xr newfs 8 87.Sh HISTORY 88The 89.Nm 90command first appeared in 91.Nx 2.0 . 92.Sh AUTHORS 93.An der Mouse 94.Aq mouse@rodents.montreal.qc.ca 95.Pp 96A big bug-finding kudos goes to John Kohl for finding the rotational 97layout bug referred to in the 98.Sx WARNING 99section above. 100.Sh BUGS 101Has not been tested and probably won't work on opposite-endian file 102systems. 103.Pp 104Can fail to shrink a file system when there actually is enough space, 105because it does not distinguish between a block allocated as a block 106and a block fully occupied by two or more frags. 107This is unlikely to 108occur in practice; except for pathological cases, it can happen only 109when the new size is extremely close to the minimum possible. 110.Pp 111Has no intelligence whatever when it comes to allocating blocks to copy 112data into when shrinking. 113