lkml.org 
[lkml]   [1997]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Filesystem optimization..
    From
    Date
    hans@grumbeer.inka.de (Hans-Joachim Baader) writes:

    > In article <x74t3szrih.fsf@metal.iinet.net.au> you write:
    > >While staring dejectedly at a filesystem holding a tad of 3 million
    > >files, and looking at the 'orrible latency to open a file, it occured
    > >to me that with most usage patterns, two things are true:
    >
    > How many of these files are actually accessed within an our? Or within
    > a day?

    About 100,000 per hour. There is some cache locality, but not
    much. (The machine is running with around 300meg of ram as a disk
    cache, and stays disk bound for about 60 - 70% of the time).

    > >
    > > 1) There are very few inodes that have more than one parent
    > > (i.e. more than one filename pointing to them)
    >
    > No, a news spool of INN actually contains many hard links.

    True, but a news spool is a very unusual file system anyway.

    > > 3) On most modern hard disks, the cost of reading 4K as
    > > opposed to reading 1K is minute (it's dominated by
    > > seek times etc).
    >
    > It could actually speed up access. But I think prefetching is
    > done already anyway, at various levels.
    >
    > >Then it occured to me that if you force aligning inodes on 64 byte
    > >boundries, the addressable filesystem goes to 256gig (probably enough
    > >for now).
    >
    > No. Terabyte disk arrays already exist, and terabyte disks and files
    > will be there within a few years. If we ignore this we end up with
    > a degenerate system like Windoze.

    It doesn't limit the size of the filesystem, just requires that the
    inodes lie in the first 1/4 terabyte or first 1/2 terabyte. Not
    exactly a terrible restriction. :)

    > >Comments?? (people dying to implement such a beast? :)
    >
    > I guess something should be done, but not this way. There are
    > several new filesystems under construction. Perhaps one of these
    > can implement some optimizations.

    There are indeed a number under development, but I was more looking
    for something that would be useable in the short term.

    Ext2 is a nice fast filesystem. This is a relatively small change that
    would hopefully make it faster yet, without noticeable cost.

    Michael.

    \
     
     \ /
      Last update: 2005-03-22 13:40    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean