[lkml]   [1999]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: multiply files in one (was GNU/Linux stance by Richard Stallman)
    Larry McVoy writes:
    > : > 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.
    > :
    > : OK, so please explain the scale of what you have in mind. How big is
    > : the compressed tarball, and how big is it uncompressed?
    > :
    > : Do you plan on having a large FS (say /usr) stored in this way, or are
    > : you thinking of a selected subset?
    > Do it on a per directory basis, only for files where links == 1.
    > I wouldn't bother to compress - just putting all the files into a
    > ``tarball'' will compress them quite nicely because of the lack of
    > fragmentation. Compression isn't the point, disk access / file read
    > is the point. For a large group of small files I want 2 disk
    > accesses (inode + tarball) for all files, instead of 2/file.

    OK, fine. I'm agreeing with that principle: two seeks per file is
    expensive. Better two seeks for a whole bunch of files.

    > : Note that I'm thinking about reading-ahead the inodes *and* the
    > : blocks. If you have RAM to burn, then this looks like it should
    > : work. I'm not thinking in terms of reading ahead a few piddling
    > : blocks. I'm talking megabytes or dozens of megabytes.
    > :
    > : So with two seek operations, you can read-ahead lots of files and lots
    > : of data.
    > More brain cells, more, more, more, I want more. :-)
    > It's a transaction cost, not a platter speed cost. Read ahead does
    > not help you on small files and inodes.

    I'm still missing your point, then. The way I see it, if you read in
    dozens of megabytes of disc blocks into your buffer cache (and say a
    megabyte of inode blocks), then things should speed up a lot.

    On the first file read, you go to the inode area and read in a
    megabyte. So now a truckload of inodes blocks are sitting in RAM.
    Then you go to the data block area, and read in dozens of
    megabytes. Now truckloads of data blocks are sitting in RAM.

    On a subsequent read of another file, there is a high chance that the
    inode and data blocks are sitting in the buffer cache, so there is no
    transaction with the device.

    Combine this with reiserfs and it may perform even better.

    > Look, if things worked the way I'm describing then you should see a
    > quantum leap in small file performance. Think 10x faster and you'll
    > see that the number of I/O's have to go down by at least a factor of
    > 10.

    I don't see why my suggestion won't yield that performance
    increase. Tell me why not.



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.021 / U:8.044 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site