Subject: Re: dynamically growing ffs
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 09/13/1999 23:36:05
> Is there anything to prevent someone hacking up fsck_ffs to increase
> fs->fs_size and everything else that is calculated from it, in order
> to add addotopma; unstriped ccd or raidframe space?

"addotopma;"?  You need to move your right hand one key left. :-)

Well, it's not fsck_ffs, but quite a while ago I wrote a program
fsresize to resize FFS filesystems on-disk.  It turned up a bug in the
rotational layout code, which as I recall was in fsck - my code was not
generating correct layout tables, fsck didn't notice, and the kernel
panicked.

I thought I'd created a version which deliberately corrupts the
cylinder group data to force fsck to recompute them, but I can't find
it now.  (Obviously, it would be better to make fsresize DTRT; since
this was discovered (IIRC, credit for this discovery belongs to bouyer)
I haven't had time to mess with it much.)

Modulo that bug, it's believed to work, and can also shrink
filesystems, though this tends to be slow because it (in general) has
to move data, not just write new cg header blocks.

In case any of you developers want to do anything with it, I've put
copies of the program and its manpage in ~mouse on cvs.netbsd.org,
under the names fsresize.c and fsresize.8; for the non-developers among
you, I'll be happy to mail out copies.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B