All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: EXT4-ish "fixes" in UBIFS
Date: Fri, 27 Mar 2009 14:48:10 +0200	[thread overview]
Message-ID: <49CCCB0A.6070701@nokia.com> (raw)

UBIFS has exactly the same properties like ext4 - in case
of power cuts:

1. truncate/write/close leads to empty files
2. create/write/rename leads to empty files

UBIFS is used in hand-held and and power-cuts are very
often there, because users just remove battery often.

I realize the "reality is different" argument, and already
concluded that we need a similar changes as Theo has done
for ext4:
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=bf1b69c0db7f9b9d8f02e94d40b19fca8336b991
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=f32b730a69bd56c5c9d704d8b75f03e90e290971
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=8411e347c3306ed36b8ca88611bf5fbf4d27d705

We have a problem that user-space people do not want to
use 'fsync()', even when they are pointed to their code
which is doing create/write/rename/close without fsync().

They just say - this is file-system bug, it is fixed in
ext4 now, just fix the bug in UBIFS.

I tell them, that is not a fix, that is band-aid, because
ext4 issues asynchronous write, and a power cut can lead
to corruptions anyway.

I tell them, we can make this in UBIFS, but please, anyway
add fsync() to your application. They say - now, we will
will not - you fix your UBIFS.

And because there is so much flood and about this, it is
so difficult to have reasonable arguments. I want to say
people - please, still use fsync(), if this is about the
performance/reliability trade-off - make it optional.
But they instead say - respected people are on our side,
go away. And point me this:
http://www.advogato.org/person/mjg59/diary/195.html
http://thread.gmane.org/gmane.linux.kernel/811167/focus=811700
http://article.gmane.org/gmane.comp.lang.perl.perl5.porters/67352

And they say that BTRFS and XFS are going to fix userspace
as well, and point me at this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/175

This all became so messy and controversial. What should I do
to persuade userspace to use 'fsync()' even if we hack UBIFS
similarly to ext4? Suggestions?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

             reply	other threads:[~2009-03-27 12:53 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 12:48 Artem Bityutskiy [this message]
2009-03-28  1:22 ` EXT4-ish "fixes" in UBIFS Kyungmin Park
2009-03-29 12:31   ` Artem Bityutskiy
2009-03-29 12:54     ` Artem Bityutskiy
2009-03-29 12:26 ` replace() system call needed (was Re: EXT4-ish "fixes" in UBIFS) Pavel Machek
2009-03-29 12:42   ` Artem Bityutskiy
2009-03-29 12:50     ` Pavel Machek
2009-03-29 13:00       ` Artem Bityutskiy
2009-03-29 13:02         ` Pavel Machek
2009-03-29 13:07           ` Artem Bityutskiy
2009-03-29 13:22             ` Andreas T.Auer
2009-03-29 13:55               ` Artem Bityutskiy
2009-03-29 13:40             ` Pavel Machek
2009-03-29 13:57               ` Artem Bityutskiy
2009-03-29 14:00                 ` Pavel Machek
2009-03-30 17:19       ` Ric Wheeler
2009-03-30 22:11         ` Pavel Machek
2009-03-29 13:01     ` Andreas T.Auer
2009-03-29 13:06       ` Artem Bityutskiy
2009-03-30 15:58   ` Diego Calleja
2009-04-03  0:09 ` EXT4-ish "fixes" in UBIFS Christian Kujau
2009-04-03  0:24   ` Trenton D. Adams
2009-04-03  0:28     ` Trenton D. Adams
2009-04-03  0:38       ` Christian Kujau
2009-04-03  0:54         ` Trenton D. Adams
2009-04-03  0:54         ` Trenton D. Adams
2009-04-03  0:59           ` Trenton D. Adams
2009-04-03  1:55       ` David Rees
2009-04-03  2:05         ` Trenton D. Adams
2009-04-03  2:19           ` David Rees
2009-04-03  2:28             ` Trenton D. Adams
2009-04-03  2:58               ` David Rees
2009-04-03  3:13                 ` Trenton D. Adams
2009-04-03  3:14                   ` Trenton D. Adams
2009-04-03  5:02                 ` Theodore Tso
2009-04-03  5:15                   ` Trenton D. Adams
2009-04-03  6:30                     ` Theodore Tso
2009-04-03 18:53                       ` Chris Adams
2009-04-03 18:05                   ` David Rees
2009-04-09 20:17                   ` Pavel Machek
2009-04-03  2:26         ` Trenton D. Adams
2009-04-03  2:05   ` Theodore Tso
2009-04-03  2:45     ` Christian Kujau
2009-04-03  2:49       ` Trenton D. Adams
2009-04-03  6:53   ` Artem Bityutskiy
     [not found] <cmFiD-8uc-9@gated-at.bofh.it>
     [not found] ` <cmFss-ft-15@gated-at.bofh.it>
     [not found]   ` <cmFsu-ft-23@gated-at.bofh.it>
     [not found]     ` <cmGRt-2hq-7@gated-at.bofh.it>
     [not found]       ` <cmH1b-2K0-11@gated-at.bofh.it>
     [not found]         ` <cmHkz-3d3-5@gated-at.bofh.it>
     [not found]           ` <cmHkA-3d3-7@gated-at.bofh.it>
     [not found]             ` <cmHND-3Oz-5@gated-at.bofh.it>
     [not found]               ` <cmJPm-7hd-5@gated-at.bofh.it>

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=49CCCB0A.6070701@nokia.com \
    --to=artem.bityutskiy@nokia.com \
    --cc=linux-kernel@vger.kernel.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 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.