From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: NeilBrown <neilb@suse.de>, Al Viro <viro@zeniv.linux.org.uk>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>, Daire Byrne <daire@dneg.com>,
Andreas Dilger <adilger.kernel@dilger.ca>
Subject: Re: [PATCH/RFC] VFS: support parallel updates in the one directory.
Date: Wed, 23 Feb 2022 20:43:28 -0800 [thread overview]
Message-ID: <20220224044328.GB8269@magnolia> (raw)
In-Reply-To: <20220222224546.GE3061737@dread.disaster.area>
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@fromorbit.com
next prev parent reply other threads:[~2022-02-24 4:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 2:24 [PATCH/RFC] VFS: support parallel updates in the one directory NeilBrown
2022-02-22 19:07 ` J. Bruce Fields
2022-02-22 21:11 ` J. Bruce Fields
2022-02-24 5:08 ` NeilBrown
2022-02-24 21:23 ` J. Bruce Fields
2022-02-22 22:45 ` Dave Chinner
2022-02-24 4:43 ` Darrick J. Wong [this message]
2022-02-24 5:56 ` NeilBrown
2022-02-24 16:31 ` Andreas Dilger
2022-02-24 23:38 ` Darrick J. Wong
2022-02-25 23:16 ` Dave Chinner
2022-02-28 0:55 ` NeilBrown
2022-03-10 11:10 ` Daire Byrne
2022-02-25 23:07 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220224044328.GB8269@magnolia \
--to=djwong@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=daire@dneg.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).