Date: Fri, 16 Aug 2002 01:27:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Patrick Thomas <root@utility.clubscholarship.com> Cc: Daniel O'Connor <doconnor@gsoft.com.au>, freebsd-hackers@FreeBSD.ORG Subject: Re: possible to expand a file for vn-device FS usage ? Message-ID: <3D5CB788.225785BA@mindspring.com> References: <20020816003225.K58763-100000@utility.clubscholarship.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Patrick Thomas wrote: > Thank you for the very clear explanation. Does there exist a utility to > immediately take a partition that has been growfs'd and "fix" it so that > it does not experience this performance penalty ? > > That is, I am willing to sit and wait 10 minutes while some utility > rearranges and reorganizes the unmounted filesystem if it means I don't > have to dump/restore/blah/blah and if it allows me to avoid the > performance penalty you mentioned... You are talking about a defragmenter. It's possible to write one of these, but no one has written one yet, because no one really uses growfs(8) often enough that it ever becomes an issue. So the short answer is "no". The longer answer is that all a defragmenter would do is "make this disk look like it would have looked had i been this size all along". The easiest way to do this is a backup and restore. Note that this does not require a tape drive, if you have enough disk space for the dump image, so it's not like this will be an incredibly time consuming process or anything. How long it would take really depends on the size of your disks, and whether you can use a different drive for the backup image or not (concurrent access to the same disk with a lot of seeks will slow the process by a factor of ~3 on most IDE based systems). The even longer answer is that this sort of thing could forcibly migrate files away from an area of the disk, so it could be used to resize a disk *smaller* (something that isn't supported at all right now), or support relocation and resizing (ala the Power Quest "Partition Magic" program). I actually volunteered to write this code for "$1 and other valuable considerations" for Power Quest, Inc., to get them to support FFS with their tools, several times, but they were not interested. The offer still stands for them; without a payoff like FreeBSD support in the best commercial partitioning product, though, it's probably not worth it just as a standalone project, without cash being involved. Conceptually, if you want to write this code, of it's very easy; all you have to do is create an image of the metadata allocations as they would look on a disk of the appropriate size, if all the files were newly created for the first time, and then rewrite the disk contents to match the image your program has in mind. You can even make it incrementally restartable, by using a file to store the image, and another small file for an intention log, in case there is a power failure during the operation. This assumes that there is enough slack disk space around for you to store the log, and that you can make the log non-colliding with the rest of the FS contents (fairly easy, actually: treat it as an already relocated file in the new FS, and temporarily move file contents around, "fragmenting them worse" to clear the area where you plan to put the log). -- Terry 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?3D5CB788.225785BA>