> 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
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
