Date: Wed, 21 Mar 2001 07:11:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: fschapachnik@vianetworks.com.ar Cc: freebsd-fs@FreeBSD.ORG Subject: Re: growfs Message-ID: <200103210711.AAA22512@usr05.primenet.com> In-Reply-To: <200103201754.OAA69131@ns1.via-net-works.net.ar> from "Fernando Schapachnik" at Mar 20, 2001 02:54:57 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I was wondering how usable is the growfs implementation > available in -CURRENT. > > Any chance of using it on -STABLE? It will work as well as it works pretty much everywhere, going back a long time. I believe the first version from "Der Mouse" ran on FreeBSD 1.1.5. The problem with this is that you will get fragmentation; consider the following two cases; the first is a disk of size "10"; the second is a disk of size "6" that has been "grown" to size "10". The "*" are allocated blocks, and the "." are unallocated blocks; "o" are blocks that would have been allocated in the new space, if it had been there at the time the were allocated (but it wasn't): .*.*..*.*.***..*.**. 01 .*o*oo*.*o***.o*o**. *..**.*.**.*****.*.. 02 *.o**o*o**.*****o*oo **.**.***...*.*.***. 03 **o**o***.oo*o*o***. .**..*.*.**.**.**.** 04 .**oo*o*o**o**o**.** *...***..****.*.*..* 05 *.o.***.o****o*o*oo* ..**..**..****.*.**. 06 oo**o.**oo****o*.**o .*..***..**.*.*.*.*. 07 .................... ***.*..*..*..*..**.. 08 .................... ..*.*.**..**.***..*. 09 .................... .*..***.*..*..*..*.. 10 .................... You see, blocks are allocated by picking empty space in a random cylinder, and at less than an 85% fill, there is effectively a 99.98% probability of not getting a collision and having to retry (the allocation policy is effectively a hash, and that's why FFS filesystems do not fragment in the first place, unless they are overfilled or someone foolishly reduces the free reserve space -- see Knuth "Seminumerical Algorithms: Sorting and Searching"). So effectively, by growing the disk, you make FFS need a defragmenter, since the probability of an allocation being tried in line "08" is the same as it being tried in line "03". So it's OK for an administrator who is willing to take a (perhaps significant) performance hit, in trade for not having to do a backup and restore, but it's pretty useless for the general case. If you decide to write an FSS defragmenter over this (it's possible to write on, but until you change the size of an FS, it's a pretty useless piece of software), then you should build it so that it can migrate data out of either the start or end of an FF, by taking one or both of those areas as not being locations where data will be relocated to during defragmentation. Doing this would let you shrink FFS partitions, as well, by defragging the data out of the area which you are going to make "go away". In general, doing this to the end of a disk is significantly easier than the start of the disk, since you will have a difficult time relocating superblock and other information not specifically associated with a cylinder group (e.g. boot code, disklabels, etc.). A better soloution for doing that would be to simply shrink it from the end, and then use a non-destructive (end byte first) data copy to relocate the entire filesystem further down on the disk, leaving the relative block offsets intact (rewriting would require you to renumber the block offsets after moving the start after you clear out the front of the disk). Much of this goes to hell during a power outage; migrating the data safely is a much harder problem; in doing that, you would copy the data first, then modify the metadata to point to the copy instead of the original, so that in case of a power failure, metadata pointing to one instead of the other would still be valid, and you could pick up where you left off. The same goes for metadata, as well, but it's just an additional level of complication. Personally, I've always found at this point that people lose interest, and deside it's easier to backup their FS data, repartition the disk, and restore from the backup... 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?200103210711.AAA22512>