On Wednesday, April 11, 2001 01:15:58 PM -0400 Derek Atkins <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
