From owner-freebsd-hackers Tue Oct 31 0:47:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id B307137B4C5 for ; Tue, 31 Oct 2000 00:47:47 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id BAA03606; Tue, 31 Oct 2000 01:44:30 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpdAAAdda49g; Tue Oct 31 01:44:26 2000 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id BAA28086; Tue, 31 Oct 2000 01:47:38 -0700 (MST) From: Terry Lambert Message-Id: <200010310847.BAA28086@usr02.primenet.com> Subject: Re: Filesystem holes To: dillon@earth.backplane.com (Matt Dillon) Date: Tue, 31 Oct 2000 08:47:38 +0000 (GMT) Cc: ryan@sasknow.com (Ryan Thompson), freebsd-hackers@FreeBSD.ORG In-Reply-To: <200010300316.e9U3GiP72404@earth.backplane.com> from "Matt Dillon" at Oct 29, 2000 07:16:44 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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