From: "J. Bruce Fields" <bfields@fieldses.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, david@sigma-star.at,
tytso@mit.edu, dedekind1@gmail.com, adrian.hunter@intel.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
adilger.kernel@dilger.ca, akpm@linux-foundation.org,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH 3/6] ubifs: Use 64bit readdir cookies
Date: Thu, 29 Dec 2016 11:59:20 -0500 [thread overview]
Message-ID: <20161229165920.GA29744@fieldses.org> (raw)
In-Reply-To: <224abf2f-c820-5df1-6292-42c1e2d47933@nod.at>
On Thu, Dec 29, 2016 at 05:36:35PM +0100, Richard Weinberger wrote:
> Bruce,
>
> On 29.12.2016 17:15, J. Bruce Fields wrote:
> > On Thu, Dec 29, 2016 at 04:49:54PM +0100, Richard Weinberger wrote:
> >> Bruce,
> >>
> >> On 29.12.2016 16:34, J. Bruce Fields wrote:
> >>>> That way UBIFS can provide a 64bit readdir() cookie which is required for NFS3.
> >>>
> >>> Sounds good. And if a matching entry isn't found (as in the case of a
> >>> concurrent unlink), what happens? The answer must be the same as for
> >>> ext4, but I've forgotten the details.... I guess it must find the next
> >>> highest cookie (thinking of the cookie as a 64-bit integer of some kind)
> >>> that exists in the directory. And that must be the same order that
> >>> readdir normally returns entries in.
> >>
> >> If a 64bit cookie is not found, the lookup function returns -ENOENT.
> >> In UBIFS we cannot just select a higher or lower key (cookie in this case),
> >> since it is the B-tree key and would point to a completely different
> >> entry.
> >>
> >> So, in case of a concurrent unlink() one would succeed and one fail with
> >> -ENOENT. Unless I miss something that seems okay to me.
> >
> > Unlink takes (parent directory, name), not a directory cookie.
> >
> > The problem is concurrent unlink and nfs readdir. So:
> >
> > NFS server returns readdir result with cookie X
> >
> > Somebody unlinks the entry at X.
> >
> > NFS server gets readdir request with cookie X.
> >
> > Then the NFS client will get a spurious -ENOENT.
>
> Ah yes. Sorry I misunderstood your question.
> UBIFS readdir() address this already, if you ask it to readdir()
> from pos X and X is not present it will jump to the next best entry X'.
> UBIFS does so since ever.
OK, good. So the random nonce is stored with the entry, and the hash
you can always recalculate from the filename, so if you return entries
in nonce+hash order, then you can keep that order stable even across
deletes and renames.
--b.
next prev parent reply other threads:[~2016-12-29 16:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 22:02 [PATCH 0/6] UBIFS NFS export support Richard Weinberger
2016-12-01 22:02 ` [PATCH 1/6] ext4: Move is_32bit_api() to generic code Richard Weinberger
2016-12-12 22:18 ` Richard Weinberger
2016-12-12 22:29 ` Andreas Dilger
2016-12-01 22:02 ` [PATCH 2/6] ubifs: Provide a custom llseek for directories Richard Weinberger
2016-12-01 22:02 ` [PATCH 3/6] ubifs: Use 64bit readdir cookies Richard Weinberger
2016-12-29 2:58 ` J. Bruce Fields
2016-12-29 9:19 ` Richard Weinberger
2016-12-29 15:34 ` J. Bruce Fields
2016-12-29 15:49 ` Richard Weinberger
2016-12-29 16:15 ` J. Bruce Fields
2016-12-29 16:36 ` Richard Weinberger
2016-12-29 16:59 ` J. Bruce Fields [this message]
2016-12-29 17:05 ` Richard Weinberger
2017-01-03 19:52 ` J. Bruce Fields
2016-12-01 22:02 ` [PATCH 4/6] ubifs: Maintain a parent pointer Richard Weinberger
2016-12-02 9:28 ` Marcus Folkesson
2016-12-02 10:36 ` Richard Weinberger
2017-04-28 8:31 ` Hyunchul Lee
2017-04-28 9:09 ` Richard Weinberger
2016-12-01 22:02 ` [PATCH 5/6] ubifs: Implement export_operations Richard Weinberger
2016-12-01 22:02 ` [PATCH 6/6] ubifs: Wire up NFS support Richard Weinberger
2016-12-29 2:56 ` J. Bruce Fields
2016-12-29 8:48 ` Richard Weinberger
-- strict thread matches above, loose matches on Subject: below --
2017-05-21 20:20 [PATCH 0/6] UBIFS NFS export support v2 Richard Weinberger
2017-05-21 20:20 ` [PATCH 3/6] ubifs: Use 64bit readdir cookies Richard Weinberger
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=20161229165920.GA29744@fieldses.org \
--to=bfields@fieldses.org \
--cc=adilger.kernel@dilger.ca \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@sigma-star.at \
--cc=dedekind1@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=tytso@mit.edu \
/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).