home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!wupost!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!pasteur!cory.Berkeley.EDU!johnm
- From: johnm@cory.Berkeley.EDU (John D. Mitchell)
- Newsgroups: comp.software-eng
- Subject: Re: Extent-based Filesystems (was: Large Application data sets )
- Message-ID: <1992Jul24.022239.5345@pasteur.Berkeley.EDU>
- Date: 24 Jul 92 02:22:39 GMT
- References: <1992Jul22.151535.25117@nuchat.sccsi.com> <3587@keele.keele.ac.uk> <13711@auspex-gw.auspex.com>
- Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
- Organization: University of California, at Berkeley
- Lines: 26
- Nntp-Posting-Host: cory
-
- In article <13711@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
- >>Surely sparse files are just a space optimisation, a compression, performed
- >>invisibly by the filesystem?
- >
- >It's surprising how often "surely", in a USENET posting, precedes a
- >statement that isn't, in fact, true....
- >
- >>It chooses to represent entire blocks of nuls
- >>in a compact way.
- >
- >Not *that* invisibly, on most UNIX systems and most UNIX file systems.
- [...]
-
- Actually, add-on products such as Stacker and SuperStor for DOS actually
- perform automatic file compression (modified forms of LZW I think).
- Obviously, these are not part of the underlying filesystem itself but as
- far as the application is concerned the (un)compression is invisible.
-
- I think one of the main concerns about putting this sort of thing into the
- file system itself is the speed penalty of doing the (un)compression. Has
- anybody done much work on timing these sorts of things?
-
- John D. Mitchell
- johnm@cory.Berkeley.EDU
-
- P.S. Standard disclaimers apply.
-