Re: BKL removal from find_exported_dentry()

["Jose R. Santos" <jrsantos@austin.ibm.com>]

On 03/11/04 15:10:20, Jose R. Santos wrote:
> Looking at the code it seems there is a possibility of racing if directories
> get rename or remove, but BKL doesn't seem to protect against these races, it
> may slow down thing a bit to avoid them though.

After looking at this even further, I'm starting to get the impression that the
BKL is there in order to protect against filesystems that behave badly.  I guess
this is the price for code portability across many filesystems.

Could a better choice to fix this issue be to implementing the get_dentry() for 
each filesystem and making sure that it almost always returns a connected dentry?
Filesystems that don't implement it would just use the generic op. 

I also have concerns about seeing this on busy SMP machines with relative small 
amounts of memory and several NFS exports with very deep directories.

> I'm attaching a patch that removes BKL from find_exported_dentry().  I see a 
> huge improvement on SpecSFS benchmark and haven't seen any failure up to date.

While reduces the time spent on find_exported_dentry() from 75% to less than 1%,
it seems that this may not be a very popular approach.  Guess I should have done 
my homework about the BKL removal subject before posting. :)

I am really interested in knowing if the BKL is there to protect against bad 
filesystem or if its there for other reasons.

Thanks

-JRS




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs