On Monday February 19, [EMAIL PROTECTED] wrote:
>
>
> On Tuesday, February 20, 2001 11:40:24 AM +1100 Neil Brown
> <[EMAIL PROTECTED]> 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?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
