[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 10:35:32 -0500


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
> 
>