Re: problems with reiserfs + nfs using 2.4.2-pre4

[Neil Brown]

On Monday February 19, [e-mail] wrote:
> 
> 
> On Tuesday, February 20, 2001 11:40:24 AM +1100 Neil Brown
> <[e-mail]> wrote:
> > 
> >   When reiserfs came along, it abused this, and re-interpreted the
> >   opaque datum to contain information for recalling (locating) an
> >   inode - if read_inode2 was defined.  I think this is wrong.
> >
> 
> I suggested to Al Viro a while ago to break iget up into two calls, and
> then got sucked into something else and didn't follow up.  Independently,
> he came up with the below message during a thread on fs-devel about
> read_inode.  I think it is very similar to what you've described, and it
> should work.  I'm willing to help integrate/code once things settle down
> for 2.4.

I must have missed that thread...
Yes, what Al Viro suggests is exactly the same idea as mine, except
that I suggest leaving iget as it is and getting the filesystem to do
a bit of locking.

> 
> His last paragraph is also important, I'd rather see this as a new
> call...BTW, I believe XFS and GFS actually have 64 bit inode numbers, while
> reiserfs has a unique 32 bit inode number (objectid) and a unique 32 bit
> packing locality that are both required to find the object.

I think the particular need for a new call is to handle long inode
identifiers better.  The current iget4 is a bit ugly.
If/when a new iget is done to handle long identifiers elegantly, it
would probably be good to include the I_NEW stuff as well, but for now
(2.4) both long identifiers and delayed fill-in can be done without
changing iget.

NeilBrown

(what's happened to Al Viro anyway, he has been awfully quite lately?)