[reiserfs-list] RE: [OpenAFS-devel] weird issue with reiserfs on 2.4.3 and openaf s

[Chris Mason]

On Wednesday, April 11, 2001 01:15:58 PM -0400 Derek Atkins
<warlord@MIT.EDU> wrote:

> The real problem is that AFS is trying to be agnostic to the
> underlying file system where the cache resides and reiserfs doesn't
> support the agnostic interface that AFS is using.  If there were a
> better FS-agnositic get-file-from-inode-number interface, I'd be happy
> to change AFS to use it.
> 
> The way the AFS client works is: A user-space daemon walks the cache
> directory and does a 'stat()' of each file.  It then passes the inode
> number obtained from the stat() down into the kernel, and then kernel
> then, at a later time, opens that inode using the passed-in inode
> number.  The problem with reiserfs is that this inode number is
> insufficient..  And yes, I consider this a problem with reiserfs,
> because it's breaking the inode number model.
> 

Grin, we could spend many hours debating this, but the simple truth is that
even if I agreed with you (which I do), the reiserfs disk format isn't
going to change.  reiserfs inode number are unique, but not enough to find
the file.  If/when the kernel switches to 64 bit inode numbers, we'll be
ready.

Until then, I'd like to find a way to make reiserfs+AFS play nice.  This
either means keeping the inodes pinned (ick), or finding a way to have AFS
sends us the extra 32 bits.  I'm more than willing to help out with that,
we just need somewhere in AFS to store the 32 bits.

-chris