Date: Thu, 15 Jul 1999 02:35:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: regnauld@ftf.net (Phil Regnauld) Cc: davids@webmaster.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907150235.TAA12574@usr07.primenet.com> In-Reply-To: <19990714204622.17443@ns.int.ftf.net> from "Phil Regnauld" at Jul 14, 99 08:46:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> FFS is even better: it doesn't fragment. Sort of. It fragments after reaching better than 85% fill, and the more over this it goes, the more it fragments. In addition, although it's relatively trivial to expand a partition size (either by editing the disklabel to use contiguous free space, or by using Vinum or ccd to define a larger logical drive), doing so will not cause the simple hash to prefer the new area until it reaches an equivalent fill. The result is that, if the total fill in the original (now sub-) region exceeds 85%, that region suffers increased fragmentation. This means that if you have a 3G FS and you expand it to a 4G FS, you should expect significant fragmentation. The generally recommended "fix" for this is backup, then restore, the files, but a "defragmenter" that caused the data to be rehashed forcefully so that all cylinder groups has equivalent fill would be a better approach. Similarly, you can't reduce the size of an FFS partition. A defragmenter that could be told "this zone is off limits" would also be useful for shrinking FFS partitions. 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907150235.TAA12574>