Messages in this thread | | | Date | Mon, 29 Mar 1999 16:58:01 -0800 | From | Steven Roberts <> | Subject | Re: multiply files in one (was GNU/Linux stance by Richard Stallman) |
| |
Larry McVoy wrote: > : > 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. > > THINK. You guys aren't THINKING. It is very FRUSTRATING. > > If you have 200 small files and you have to go get 200 inodes and 200 blocks > to read them in, the inodes and the blocks aren't next to each other, that's > 400 disk transactions instead of 1. THINK. PLEASE. This is the third time > I've gone over this point.
Just to help your sanity, I hear you Larry, and agree with what you are saying.
Of course, I'm thinking a userfs solution would work here.
sidenote: Does anyone know if there is a workable user fs patch set anywheres for 2.2.x?
I had something like this going under a pseudo win95 userfs a while back, and am working on a reimplementaion that will work both on win95 and on linux. For the stuff I'm doing at least userfs would be cleanest. I'm thinking keeping the code for tar/gzip/bzip2/zip/... out of the kernel would be a good thing.
Of course you get the cool side benefit of doing: cd foo.tar
Steve
- 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/
| |