From: Richard Weinberger <richard@nod.at>
To: Nikhilesh Reddy <reddyn@codeaurora.org>
Cc: linux-mtd@lists.infradead.org, Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] ubifs: Add new mount option to force fdatasync before rename
Date: Tue, 29 Sep 2015 19:52:28 +0200 [thread overview]
Message-ID: <560ACFDC.1010100@nod.at> (raw)
In-Reply-To: <560AC4AA.1070906@codeaurora.org>
Hi!
Am 29.09.2015 um 19:04 schrieb Nikhilesh Reddy:
> Unfortunately major changes would not be completely up to me :(
hm?
> But before i spend time on it ... i was hoping to understand the disadvantages of this approach and the advantages of the other approach?
> Can you kindly help me understand?
Sure.
Instead of making rename() unconditionally synchronous we could do it like ext4 and detect rename+close patterns and make only
these synchronous.
So, your application does:
fd = open("foo", ...)
write(fd, "yadda yadda, ...)
close(fd)
rename("foo", "bar")
and then expects "bar" to exist with contents "yadda yadda"?
I'm asking because we also have to make sure that this is not an UBIFS bug.
We have to be careful, ext4 has a metadata journal, UBIFS' is different.
My point is that UBIFS better should detect the close+rename pattern then only then do rename synchronous.
> So the patch effectively converts all the rename to a fdatasync+rename which is what we would expect all the userspace applications to do anyway.
But there are also cases where you want a fast rename() and sync later.
Artem, what do you think?
Thanks,
//richard
next prev parent reply other threads:[~2015-09-29 17:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-28 18:19 [PATCH] ubifs: Add new mount option to force fdatasync before rename Nikhilesh Reddy
2015-09-28 19:38 ` Richard Weinberger
2015-09-28 20:38 ` Nikhilesh Reddy
2015-09-28 20:49 ` Richard Weinberger
2015-09-29 17:04 ` Nikhilesh Reddy
2015-09-29 17:52 ` Richard Weinberger [this message]
2015-10-02 21:38 ` Richard Weinberger
2015-10-05 18:05 ` Nikhilesh Reddy
2015-10-06 8:09 ` Richard Weinberger
2015-10-13 18:41 ` Nikhilesh Reddy
2015-10-15 19:16 ` 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=560ACFDC.1010100@nod.at \
--to=richard@nod.at \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=reddyn@codeaurora.org \
/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).