Re: multiply files in one (was GNU/Linux stance by Richard Stallman)
Mark H. Wood (mwood@iupui.edu)
Tue, 30 Mar 1999 14:16:15 -0500 (EST)
On Tue, 30 Mar 1999, Richard Gooch wrote:
> Larry McVoy writes:
> > : > Please show me the design of a file system which can bring in multiple
> > : > small files with a single seek and read. When you get done, you'll be
> > : > looking at what I described.
> > :
> > : Seek and read which files? If you want anything but all files, you're
> > : probably out of lock. Again, you will have to seek if any of the
> > : files are fragmented (which is the case with most fs).
> >
> > Your still missing the performance implications. In many, many typical
> > cases (and this will become more and more true as memory gets cheaper),
> > it would be far faster to eat the whole tarball and explode it into a
> > bunch of in memory files even to get just a few of the files. Work
> > through the math - if each file costs you a seek, you only need to get
> > to 2-3 files before it would be faster to get 'em all.
>
> Hm. But do we need a special FS for this? In theory, isn't this
> covered by a sufficiently aggressive read-ahead mechanism at the block
> layer and in the drive itself? If the HDD reads in a whole sector into
> its cache, that will contain a fair number of small files.
VMS does something like this in userspace. It's called the Librarian.
(The VMS Librarian is probably not designed to current thinking, i.e.
assume you can cheaply plug more memory into the box until your file fits
entirely in core, but probably tries to read and write in huge gulps.)
Anyway it's been done before and never abandoned, so there must've been a
reason.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Specializing in unusual perspectives for more than twenty years.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/