Date: Sat, 28 Aug 1999 22:49:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ticso@cicely.de (Bernd Walter) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: fs-locking and fs memory copies questions Message-ID: <199908282249.PAA06168@usr01.primenet.com> In-Reply-To: <19990828201723.A27704@cicely8.cicely.de> from "Bernd Walter" at Aug 28, 99 08:17:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I would like to grow a ufs filesystem without the need to umount it before. > The growing itself will be possible for me in the near future without any > problems. > > Before doing it while the fs is mounted I need to flush all blocks back to > the partition and lock the fs until the fs-strucktures are all updated. > All programs should block during the lock. > Is it possible to flush relieable with softupdates? running "mount -u" on the FS in question does this. > After the strucktures are up to date I need to reread the superblock and > all in memory copies of the previously last cg and all derived variables. You will need to modify code to do this. The "mount -u" code doesn't cause the in core data to be re-read, and doesn't sync out data to a "clean" state. The code you need to modify is in ffs_mount in ffs_vfops.c. > In some cases it is needed that I reallocate some frags/blocks. This is the problem with growing FS's: the hash fill on the preexisting cylinger groups will be higher than on the new cylinder groups, leading to fragmentation. There are two ways around this, one good, one bad. I expect you'll want to use the "bad" way: Good: Defrag the drive by either writing and then running a defragger, or by backing up and restoring files. You could copy the files in place, if you had enough disk, and used a holey copy program (e.g. GNU tar). Bad: Give preference to the new CG's for all allocations; the problem with this is, you never know when to stop doing this. 8-(. > That means that cg 0 has changed and maybe some other cgs I used > to move the frags to. That also means that at least one inode > or indirection block have beend modified and of course that in > memory references to diskblocks of indirection and/or > datablocks need to be updated. > Finally the locks need to be removed and all waiting operations can continue. I think you will find an "on the fly" defragger a difficult thing to write. > I would be happy if someone can explain or point me to a good documentation > about internal operations regarding the points I need. The above will get you started. A generic defragger would be a good think to have, if you wanted to allow shrinking partitions, too. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908282249.PAA06168>