Messages in this thread | | | Subject | Re: multiply files in one (was GNU/Linux stance by Richard Stallman) | Date | Tue, 30 Mar 1999 08:54:32 +0200 (MEST) | From | (Rogier Wolff) |
| |
Jon Bright wrote: > Larry McVoy wrote: > > > 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.
> And if you have 200 small files spread about in a pseudo-tarball of > 4000 files? Or say your tarballs only cover 200 files at a time, > you have 200 files spread through 20 pseudo-tarballs? And just how > frequent an operation is it for something to read 200 small files > in? And if it's that frequent, then (admittedly you lose on the > first time), they'll (hopefully) still be cached for the second and > subsequent occasions?
Just look at it this way: Suppose the parameters of the disk say that you can readahead 64k for "Free". Say I have a directory with 500 small files. (whatever the limit is, memory, bandwidth, hitrate-chances: you need to put a limit on the readahead somewhere....)
In the old situation that readahead would contain 64 files. So opening a random other file will have a 10% chance of being in the cache, not requiring another IO.
In the new situation, the 500 files would only occupy say 150k on the disk. So the readahead hits 40% of the files, giving a 40% hitrate on the next file.
The extra hitrate is for free (in terms of IO). That's what makes it attractive.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
- 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/
| |