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