Alexander Viro writes:
>
> On Wed, 14 Jun 2000, Richard Gooch wrote:
Sigh. It's taken me far to long to get back to this.
> > > Not only that, actually - order of invalidation was incorrect, IIRC.
> >
> > Let me check I understand what you mean. You're concerned about the
> > way I *invalidate
Alexander Viro wrote:
> One word: modules. Oh, and Linus is not alone in distaste to ifdefs.
You can ifdef based on whether module support is compiled in.
>
> This union is an old design mistake and it actually used to be worse -
> named pipes also were there. By chance it worked on ext2 and m
On Fri, 16 Jun 2000, Hans Reiser wrote:
> Dropping dentries could easily be much harder to code in the general case, and
> your resisting that suggestion is very reasonable, but we are pie-in-the-skying
> right now, so I said what I did. I will further pie-in-the-sky and suggest that
> perhaps
Alexander Viro wrote:
> ??? inodes are not in dcache. Dentries are, and without them lookups will
Forgive my imprecision of statement.
> kill you + you'll have a dubious pleasure to reproduce all race-preventing
> code of VFS in your replacement mechanism. Which is pretty likely to bring
> you s
On Tue, 13 Jun 2000, Hans Reiser wrote:
> There are desired applications of reiserfs where the VFS inode is just too
> heavyweight. I'd just like to say that this seems like a good concern you have
> here, and the ReiserFS team is completely willing to recode in 2.5.* to
> accomodate your radi
On Thu, 15 Jun 2000, Theodore Ts'o wrote:
>Date: Tue, 13 Jun 2000 13:10:48 -0400 (EDT)
>From: Alexander Viro <[EMAIL PROTECTED]>
>
>Start from taking ext2, UFS and NFS out of ->u. in struct inode. Yup,
>separate allocation and inlined function (ext2_ino(inode)) that would
On Wed, 14 Jun 2000, Richard Gooch wrote:
> > Not only that, actually - order of invalidation was incorrect, IIRC.
>
> Let me check I understand what you mean. You're concerned about the
> way I *invalidate*, rather than the way I *revalidate*?
Watch for interaction between
* your inv
Date:Tue, 13 Jun 2000 13:10:48 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
Start from taking ext2, UFS and NFS out of ->u. in struct inode. Yup,
separate allocation and inlined function (ext2_ino(inode)) that would
return the pointer to private part of inode. I can
Alexander Viro writes:
>
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > > Yes. And all that time mounting the thing at several point was a huge,
> > > fscking hole.
> >
> > Sure. And hence RedHat wasn't going to compile it in.
>
> Fine with RedHat, but how in hell does it solve the probl
On Tue, 13 Jun 2000, Richard Gooch wrote:
> > Yes. And all that time mounting the thing at several point was a huge,
> > fscking hole.
>
> Sure. And hence RedHat wasn't going to compile it in.
Fine with RedHat, but how in hell does it solve the problem? I don't
_CARE_ for any "party line". I
On Tue, 13 Jun 2000, Richard Gooch wrote:
> I'd like to see something more drastic. Indeed, that union crap is by
> far the worst offender and needs fixing. But there's a whole pile of
> other junk that's just not needed all the time.
Richard, may I remind you that we are supposed to be in the
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > I'd like to see something more drastic. Indeed, that union crap is by
> > far the worst offender and needs fixing. But there's a whole pile of
> > other junk that's just not needed all the time.
>
> Richard, may I remind
On Tue, 13 Jun 2000, Richard Gooch wrote:
> > Richard, may I remind you that we are supposed to be in the freeze?
> > There may be a chance to trim the union down _and_ get it into 2.4.
>
> ??? Didn't you read the other parts of my message. Quoting myself:
>
> > Besides, there's also the prob
Richard Gooch wrote:
>
> Hi, Al. I'd like to explore an idea Linus suggested a while back. He
> suggested using VFS inodes as the data store for devfs, rather than
> keeping stuff in devfs entries. So the idea would be that the VFS
> maintains the tree structure rather than devfs entries.
>
>
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > Alexander Viro writes:
> > >
> > > On Tue, 13 Jun 2000, Richard Gooch wrote:
> > > > So I don't really expect wholesale VFS changes right now (but, hey,
> > > > that doesn't seem to stop you getting stuff in;-). But that
Hans Reiser writes:
> Richard Gooch wrote:
> > Another idea (probably too radical, and also CPU inefficient), is a
> > super lightweight inode that has just two pointers: one to FS-specific
> > data, another to FS-specific methods. The methods are used to
> > read/write inode members, so each FS c
On Tue, 13 Jun 2000, Richard Gooch wrote:
> Alexander Viro writes:
> >
> > On Tue, 13 Jun 2000, Richard Gooch wrote:
> > > So I don't really expect wholesale VFS changes right now (but, hey,
> > > that doesn't seem to stop you getting stuff in;-). But that shouldn't
> >
> > They would not be
Alexander Viro writes:
>
> On Tue, 13 Jun 2000, Richard Gooch wrote:
> > So I don't really expect wholesale VFS changes right now (but, hey,
> > that doesn't seem to stop you getting stuff in;-). But that shouldn't
>
> They would not be there if not for your ability to get devfs there ;-/
> And
On Tue, 13 Jun 2000, Alexander Viro wrote:
> > Have you given any consideration to coming up with a more lightweight
> > inode structure? Either through modification of the VFS inode, or
> > creation of some kind of "generic" lightweight inode structure that
> > stores the bare essentials. Perhaps
Alexander Viro writes:
> On Tue, 13 Jun 2000, Richard Gooch wrote:
>
> > This is a lot closer to being feasible with all the VFS changes you've
> > been making, but there is one problem that really concerns me. VFS
> > inodes are very heavyweight. The devfs entries are very lightweight,
> > stori
On Tue, 13 Jun 2000, Richard Gooch wrote:
> This is a lot closer to being feasible with all the VFS changes you've
> been making, but there is one problem that really concerns me. VFS
> inodes are very heavyweight. The devfs entries are very lightweight,
> storing only that which is necessary.
Hi, Al. I'd like to explore an idea Linus suggested a while back. He
suggested using VFS inodes as the data store for devfs, rather than
keeping stuff in devfs entries. So the idea would be that the VFS
maintains the tree structure rather than devfs entries.
This is a lot closer to being feasib
22 matches
Mail list logo
