lkml.org 
[lkml]   [1998]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Filesystem optimization..
    michael@metal.iinet.net.au (Michael O'Reilly)  wrote on 30.12.97 in <x7sorby4eu.fsf@metal.iinet.net.au>:

    > Richard Gooch <rgooch@atnf.csiro.au> writes:
    >
    > > Michael O'Reilly writes:
    > > > ebiederm+eric@npwt.net (Eric W. Biederman) writes:
    > > > > MR> Even in this, there's still a win from not needing to allocate a
    > > > > MR> fixed amount of inodes.
    > > > >
    > > > > And again see btree based filesystems. There is reiserfs in the
    > > > > works, as well as my own shmfs filesystem (though because it has
    > > > > different prioirties, it doesn't yet keep all inodes in the btree) but
    > > > > basically with such a beast it is possible, to keep inodes in the
    > > > > directory tree.
    > > >
    > > > I've had a number of people point these out, but there's not a
    > > > terribly good option for me. I need a stable filesystem, so the
    > > > smallest possible change for the largest gain.
    > >
    > > Your proposed changes to ext2fs would not exactly be "smallest
    > > possible change". It could introduce all kinds of bugs.
    >
    > Yup. But it's a good deal smaller than a brand new filesystem. :)

    Actually, I'd say it _is_ a brand new filesystem. It's sufficiently
    dissimilar to ext2 that I won't count on being able to carry over any
    assumptions at all, let alone about stability.

    MfG Kai

    \
     
     \ /
      Last update: 2005-03-22 13:40    [W:0.020 / U:30.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site