[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <164600974741.15631.8678502963654197325@noble.neil.brown.name>
Date: Mon, 28 Feb 2022 11:55:47 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: "Andreas Dilger" <adilger@...ger.ca>,
"Dave Chinner" <david@...morbit.com>,
"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 Fri, 25 Feb 2022, Darrick J. Wong wrote:
> On Thu, Feb 24, 2022 at 09:31:28AM -0700, Andreas Dilger wrote:
> > On Feb 23, 2022, at 22:57, NeilBrown <neilb@...e.de> wrote:
> > >
> > > for i in {1..70}; do ( for j in {1000..8000}; do touch $j; rm -f $j ; done ) & done
>
> I think you want something faster here, like ln to hardlink an existing
> file into the directory.
>
And probably written in C too..
> (I am also not a fan of "PAR_UPDATE", since 'par' is already an English
> word that doesn't mean 'parallel'.)
:-)
We already have DCACHE_PAR_LOOKUP for parallel lookups in a directory
(though it is really a lock bit and I think should be named as soch).
So it made sense to use DCACHE_PAR_UPDATE for parallel updates.
And then S_PAR_UPDATE for the inode flag to enable this seemed logical.
But I agree that these names are sub-par :-)
NeilBrown
Powered by blists - more mailing lists