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

[Neulinger, Nathan]

Just for the hell of it, I tried doing the following:

	afsd - stat the cache file before telling kernel to open it with
iget
	afs_dcache.c - in kernel code - tell afs_InitCacheFile to
intentionally leak open files - i.e. when initting the cache files,
intentionally do not call UFSClose() on the file after the cache file has
been initialized.

I'm leery of this as a 'fix', but I am unable to trigger the failure after
doing this.

Perhaps it would be reasonable to have the kernel itself keep the files open
like this, but in a way that it could keep track of them so they can be
closed later when afs is unmounted.

I'm not sure how this sort of thing would interact with "max number of open
files" and things like that though. How do those limit behave inside the
kernel?

-- Nathan

> -----Original Message-----
> From: Neulinger, Nathan [mailto:nneul@umr.edu]
> Sent: Wednesday, April 11, 2001 10:36 AM
> 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
> 
> 
> 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
> > 
> > 
>