linux-kernel - Re: [PATCH/RFC] VFS: support parallel updates in the one directory.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220224044328.GB8269@magnolia>
Date:   Wed, 23 Feb 2022 20:43:28 -0800
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     NeilBrown <neilb@...e.de>, Al Viro <viro@...iv.linux.org.uk>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Daire Byrne <daire@...g.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: [PATCH/RFC] VFS: support parallel updates in the one directory.

On Wed, Feb 23, 2022 at 09:45:46AM +1100, Dave Chinner wrote:
> On Tue, Feb 22, 2022 at 01:24:50PM +1100, NeilBrown wrote:
> > 
> > Hi Al,
> >  I wonder if you might find time to have a look at this patch.  It
> >  allows concurrent updates to a single directory.  This can result in
> >  substantial throughput improvements when the application uses multiple
> >  threads to create lots of files in the one directory, and there is
> >  noticeable per-create latency, as there can be with NFS to a remote
> >  server.
> > Thanks,
> > NeilBrown
> > 
> > Some filesystems can support parallel modifications to a directory,
> > either because the modification happen on a remote server which does its
> > own locking (e.g.  NFS) or because they can internally lock just a part
> > of a directory (e.g.  many local filesystems, with a bit of work - the
> > lustre project has patches for ext4 to support concurrent updates).
> > 
> > To allow this, we introduce VFS support for parallel modification:
> > unlink (including rmdir) and create.  Parallel rename is not (yet)
> > supported.
> 
> Yay!
> 
> > If a filesystem supports parallel modification in a given directory, it
> > sets S_PAR_UNLINK on the inode for that directory.  lookup_open() and
> > the new lookup_hash_modify() (similar to __lookup_hash()) notice the
> > flag and take a shared lock on the directory, and rely on a lock-bit in
> > d_flags, much like parallel lookup relies on DCACHE_PAR_LOOKUP.
> 
> I suspect that you could enable this for XFS right now. XFS has internal
> directory inode locking that should serialise all reads and writes
> correctly regardless of what the VFS does. So while the VFS might
> use concurrent updates (e.g. inode_lock_shared() instead of
> inode_lock() on the dir inode), XFS has an internal metadata lock
> that will then serialise the concurrent VFS directory modifications
> correctly....

I don't think that will work because xfs_readdir doesn't hold the
directory ILOCK while it runs, which means that readdir will see garbage
if other threads now only hold inode_lock_shared while they update the
directory.

--D

> Yeah, I know, this isn't true concurrent dir updates, but it should
> allow multiple implementations of the concurrent dir update VFS APIs
> across multiple filesystems and shake out any assumptions that might
> arise from a single implementation target (e.g. silly rename
> quirks).
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@...morbit.com