On Sat, 18 Jan 2025, Jeff Layton wrote: > We've hit a number of cases in testing recently where the parent's > i_rwsem ends up being the bottleneck in heavy parallel create > workloads. Currently we have to take the parent's inode->i_rwsem > exclusively when altering a directory, which means that any directory- > morphing operations in the same directory are serialized. > > This is particularly onerous in the ->create codepath, since a > filesystem may have to do a number of blocking operations to create a > new file (allocate memory, start a transaction, etc.) > > Neil recently posted this RFC series, which allows parallel directory > modifying operations: > > https://lore.kernel.org/linux-fsdevel/20241220030830.272429-1-neilb@xxxxxxx/ > > Al pointed out a number of problems in it, but the basic approach seems > sound. I'd like to have a discussion at LSF/MM about this. > > Are there any problems with the basic approach? Are there other > approaches that might be better? Are there incremental steps we could > do pave the way for this to be a reality? Thanks for raising this! There was at least one problem with the approach but I have a plan to address that. I won't go into detail here. I hope to get a new patch set out sometime in the coming week. My question to fs-devel is: is anyone willing to convert their fs (or advice me on converting?) to use the new interface and do some testing and be open to exploring any bugs that appear? I'd like to try ext4 using the patches that lustre maintains for parallel directory ops in ext4 but making them suitable for upstream doesn't look to be straight forward. https://git.whamcloud.com/?p=fs/lustre-release.git;a=blob;f=ldiskfs/kernel_patches/patches/linux-6.5/ext4-pdirop.patch;h=208d9dc44f4860fbf27072ed1969744131e30108;hb=HEAD NeilBrown
