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

Neulinger, Nathan nneul@umr.edu
Wed, 11 Apr 2001 09:39:43 -0500


I wonder, would the workaround that we came up with for the performance
issue with 2.2 help here? i.e. opening the files with afsd prior to doing
the iget in the kernel?

In that case it was just for performance to eliminate the bad fallback. In
this case, would it still eliminate the bad fallback? Or would it just
eliminate the panic most of the time and possibly it would come back in the
case where the inode cache got flushed?

Can you get me some more details about what would need to be stored/etc. Is
there any way to code that in a reasonably filesystem independent manner?
I.e. I'd hate to have afsd/libafs have to be configured differently for
different filesystems, yuck.

-- Nathan

> -----Original Message-----
> From: Chris Mason [mailto:mason@suse.com]
> Sent: Wednesday, April 11, 2001 9:35 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 09:23:50 AM -0500 "Neulinger, Nathan"
> <nneul@umr.edu> wrote:
> 
> > The only issue I've been aware of with reiserfs+afs was the 
> one I reported
> > where it was really slow scanning the cache if it wasn't on 
> it's own FS.
> > Everything else has worked fine with 2.2.x + reiser. 
> > 
> > Or are you meaning that the iget returns bogus results? 
> Cause the error
> > check after the iget below doesn't get triggered. (The msg 
> is 'cant open',
> > not 'cant get'.)
> 
> Our 2.2 code has a fallback to handle failed igets, but our 2.4 code
> doesn't.  So, AFS will need modification to store the extra 32 bits
> reiserfs needs in finding the file for 2.4 kernels.
> 
> The search_by_objectid fallback code could be dragged into 
> 2.4, but you
> really don't want it.  It works like this:
> 
> for (i = 0 ; i < highest_inode_number_allocated ; i++) {
>     binary search through tree (i, inum provided by iget) 
> }
> 
> This is roughly as fast as searching through the media by 
> hand with your
> own magnet.
> 
> -chris
>