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.085 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site