> 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? Is it not a lot more frequent for
something to read 1 or 2 small files in, in which case you have to get (say) 2
inodes and 2 blocks, as opposed to getting 1 inode of a pseudo-tarball, 1 block
for some kind of index, then 2 blocks for the actual files? You've gained by an
inode and lost some processor time and a block? I know the maths doesn't
exactly work like this, but overall, I don't think your proposal gains in most
situations...
-- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.co.uk/
- 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/