On 2015-03-11 09:48 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 11 Mar 2015 19:03:33 -0400, Nicholas Krause said:
was wondering of how this would improve file system scalability and reliability if implemented in file system code for btrfs worker threads.
Step 1: Figure out what locks are contended in actual systems. Step 2: Determine if the scope of a contended lock can be reduced. Step 3: ??? Step 4: Profit!
Note that improving scalability will often cause reliability issues, because as you decompose locks into sets of smaller locks, you increase the number of ways you can get it wrong. The BKL, for all its uglyness, was pretty hard to screw up. On the other hand, we probably would never have gotten rid of it if somebody hadn't put lockdep into the kernel. It was painful enough even with automated testing tools....
Thanks Valdis, That makes sense to me. I was wondering however about the reader vs writer issues in file systems too as this seems to me coming up a lot in btrfs and other file systems for various reasons. Thanks Nick