Date: Tue, 31 Oct 2000 08:47:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@earth.backplane.com (Matt Dillon) Cc: ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem holes Message-ID: <200010310847.BAA28086@usr02.primenet.com> In-Reply-To: <200010300316.e9U3GiP72404@earth.backplane.com> from "Matt Dillon" at Oct 29, 2000 07:16:44 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Ahh.. yes, I know. I'm a filesystem expert :-) However, that said, I > will tell you quite frankly that virtually *nobody* depends on holes > for efficient storage. There are only a few problems where it's > practical.... some forms of executables, and sparse matrixes. That's > pretty much it. Your master password database. Most sendmail maps. Anything else that uses the Berkeley DB, like message catalog files, locales, etc.. Frankly, sparse files have a huge number of uses, particularly when applied to persistant storage of data of the kind you'd see in chapter 5, section 5.4.x and chapter 6 in Knuth's. Plus your FFS filesystem itself is a sparse matrix. It'd be real useful to be able to "free up holes" in a file, if I wanted to use one to do user space work on an FS design, for example, a log structured FS, where I wanted to be able to experiment with a "cleaner" process that recovered extents. I'd actually be able to tell real quickly whether it was working by just setting an allocation range that I expect my iterative testing to stay within (if it goes over or under the range while I'm moving stuff around and cleaning at the same time, I'll know there's a bug in my daemon). Personally, I'm not rich enough to be able to burn disk space so easily. 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?200010310847.BAA28086>