From: Tanya Brokhman <tlinder@codeaurora.org>
To: "Bityutskiy, Artem" <artem.bityutskiy@intel.com>
Cc: "draviv@codeaurora.org" <draviv@codeaurora.org>,
"richard@nod.at" <richard@nod.at>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Synchronization in UBIFS (zero length files)
Date: Sun, 01 Feb 2015 10:39:58 +0200 [thread overview]
Message-ID: <54CDE65E.2000002@codeaurora.org> (raw)
In-Reply-To: <1422709032.8637.337.camel@sauron.fi.intel.com>
Hi Artem
On 1/31/2015 2:57 PM, Bityutskiy, Artem wrote:
> On Sat, 2015-01-31 at 14:52 +0200, Artem Bityutskiy wrote:
>> Well, the idea was to implement something like BIO for UBIFS.
>
> For UBI, of course. We even started doing this at some point, but then
> stopped. At that time I was confident we could do it.
>
> The workqueue suggestion I gave may or may not work. It feels easier to
> implement and less intrusive. But you never know before you try.
>
Thanks for the explanation!
This was a while back and the task already completed :) I found a long
long discussion you had with the community back in 2009 when Ted Ts'o
implemented the sync-on-rename/truncate hack for ext4. You were asking
the developers opinion on whether same should be done for ubifs or the
sync should remain the user responsibility. The conclusion was that it's
user responsibility to sync before renaming so nothing was done for ubifs.
Unfortunately our customer thought differently so I had to go through
with adding this hack to ubifs. Not the most elegant solution to the
zero-length-files problem, but the quickest and the safest for the moment.
Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
prev parent reply other threads:[~2015-02-01 8:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 8:34 Synchronization in UBIFS (zero length files) Tanya Brokhman
2014-12-18 11:12 ` Richard Weinberger
2014-12-18 14:53 ` Tanya Brokhman
2014-12-18 15:12 ` Richard Weinberger
2014-12-23 8:26 ` Tanya Brokhman
2014-12-23 9:24 ` Richard Weinberger
2014-12-23 9:48 ` Tanya Brokhman
2015-01-31 12:52 ` Artem Bityutskiy
2015-01-31 12:57 ` Bityutskiy, Artem
2015-02-01 8:39 ` Tanya Brokhman [this message]
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=54CDE65E.2000002@codeaurora.org \
--to=tlinder@codeaurora.org \
--cc=artem.bityutskiy@intel.com \
--cc=draviv@codeaurora.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.