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

[Derek Atkins]

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.

-derek

"Neulinger, Nathan" <nneul@umr.edu> writes:

> Ya know, keeping the files open wouldn't be a half bad idea. Although it
> does mean that in some cases, the system would have 50,000 (for a 500 MB
> cache w/ standard options for chunk size) open files sitting around doing
> nothing. Seems a bit excessive.
> 
> As it stands now with the patch, it just stats the cache node, then does the
> kernel msg that triggers the iget/open. The cache node isn't kept open
> though.
> 
> True on your point about it being slow - except that it isn't actually slow
> when people put the afscache on it's own filesystem. That's what we found
> out with the 2.2.x reiserfs code. 
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Chris Mason [mailto:mason@suse.com]
> > Sent: Wednesday, April 11, 2001 10:31 AM
> > To: Neulinger, Nathan
> > Cc: 'reiserfs-list@namesys.com'; 'openafs-devel@openafs.org'
> > Subject: RE: [reiserfs-list] RE: [OpenAFS-devel] weird issue with
> > reiserfs on 2.4.3 and openaf s
> > 
> > 
> > 
> > 
> > On Wednesday, April 11, 2001 10:08:41 AM -0500 "Neulinger, Nathan"
> > <nneul@umr.edu> wrote:
> > 
> > > Unfortunately, I can only prime this at afsd startup time. 
> > Within the
> > > kernel module, the igets are issued later on when files in afs are
> > > actually accessed, and at that time, the kernel module does not know
> > > anything about the cache filenames, only the inodes. 
> > > 
> > 
> > Hmmm, is a userspace daemon doing the opens on the cache 
> > files when you
> > prime the cache?  You might be better off just keeping the 
> > cache files open
> > the whole time.  This is easier if they are done by 
> > userspace, since the
> > closes will happen if the program dies somehow.
> > 
> > > I know y'all don't like that fallback code, and it's 
> > obviously a worst
> > > case scenario, but I'd really like to see you add it back in for the
> > > simple reason that 'horribly slow' (and in this case, it 
> > won't be, since
> > > it's on it's own partition) is better than 'doesn't work at all'.
> > > 
> > > I'm not totally averse to adding it back in on my local 
> > kernel only if we
> > > can't come up with a better alternative.
> > > 
> > 
> > It is easy to patch in, but it doesn't get the real problem 
> > solved.  The
> > problem with keeping the search_by_objectid code is that 
> > instead of getting
> > proper interaction with things like AFS, people end up just thinking
> > reiserfs is slow.
> > 
> > -chris
> > 
> > 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available