Date: Sat, 28 Feb 1998 11:16:58 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: sthaug@nethelp.no, hackers@FreeBSD.ORG, grog@lemis.com Subject: Re: resizing ffs filesystems (was Re: SCSI Bus redundancy...) Message-ID: <199802281116.EAA12348@usr08.primenet.com> In-Reply-To: <199802281029.CAA01844@dingo.cdrom.com> from "Mike Smith" at Feb 28, 98 02:29:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > der mouse made an "fsresize" program for NetBSD. It can both grow and shrink > > file systems. The source is about 50 kB, I can post it here if anybody is > > interested (or you can get it from http://www.nethelp.no/scsi/fsresize.c). > > The URL is fine. Is there any anecdotal evidence as to how well this > works? It does appear to handle both expansion and contraction, which > would be a very nice thing indeed to have. It does not rehash allocations, so it has the fragmentation issues I mentioned before (ie: if the FS is very full and you grow it, the portion that is added is empty and the portion that was there prior to the add is still the same percentage full. Allocations are effectively hashing blocks onto the disk, so you still have the hash collisions in oldsize/newsize*100 percent of allocation attempts.). !!!Don't do a defragger until you read *all* of the rest of this!!! You could get an "average fill" for cylinder groups, and then take from each cylinder group, at random, and taking: oldsize/newsize*avg_blocks_allocated/blocks_in_cg worth of blocks and relocating them to the new area, hashing using the same algorithm as FFS uses, but only into the new cg's. The blocks picked should be pretty much at random in each old cg. This would be a "poor man's" defrag. The idea is to equalize the number of blocks in each cg (without cutting up clusters, of course). A better algorithm would take non-clustered block runs and cluster them, but that's a lot more work. The comment about the bug about "find_freespace" is correct; an end of file frag can *not* straddle a block boundry, so there *is* a bug there. The suggested fix seems reasonable, but the code is rather convoluted, so it'd be a bit hard to implement it in a small amount of time. The reallocation is linear on a shrink; this will probably result in the same fragmentation issues (generally, worse, since it will 100% fill cylinder groups if there is enough data that needs to be moved). You could fix this pretty easily, actually (easily in the theoretical sense; see the comment about the code, above), by employing the same allocation algorithm as FFS employs. This would guarantee that the data would be hashed into the available space equally instead of linearly. All in all, for a small hack, it's a pretty good effort. It should be safe to use to grow FS's (since the bug only bites when you attempt to move end of file frags and end up straddling a block boundry, and it doesn't attempt to defrag -- if someone adds this to it, they would need to worry about relocations when growing, as well). At least it saves me writing the expander... ;-). 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802281116.EAA12348>