public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: Helge Hafting <helge.hafting@hist.no>,
	Petter Larsen <pla@morecom.no>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ext3 <ext3-users@redhat.com>
Subject: Re: mode data=journal in ext3. Is it safe to use?
Date: Fri, 18 Jun 2004 12:30:55 +0100	[thread overview]
Message-ID: <1087558255.25904.14.camel@pmarqueslinux> (raw)
In-Reply-To: <20040618101520.GA2389@linuxhacker.ru>

On Fri, 2004-06-18 at 11:15, Oleg Drokin wrote:
> Hello!
> 
> On Fri, Jun 18, 2004 at 11:41:23AM +0200, Helge Hafting wrote:
> 
> > >If you can reproduce a garbage in files in ordered journal mode, that 
> > >would be a
> > >bug that should be fixed then.
> > Hard to _produce_, but consider:
> > 1. Write data to an existing file
> > 2. Sync metadata
> > 3. data is forced out because of ordered mode, a powerout crash happens
> >    in the middle of this. The file now has a block with a mix of new 
> > and old,
> 
> Well, this is not much worse than having two blocks, one from old file
> and one from new after a crash.

Agree. If the application needs consistency it must do some journaling
itself. At least, until the time when an application can say "start
transaction" "commit transaction" to the file system itself.

> >    it may even be unreadable due to a bad sector checksum.
> 
> Well, in data journaled mode you may get unreadable journal, is this much
> better? (Also original question was about CF flash media, so no bad sector
> problems I presume).

You got it wrong here. The sentence was "bad sector checksum", not "bad
sector". If the sector was "half written", then the checksum would not
match.

If the journal is "half written" then it is just discarded (or at least
it should be).

> > With data journalling you either get the old data (because the crash 
> > happened
> > during a write to the journal) or new data (crash happened during data 
> > write,
> 
> Well, while with data journaling mode your granularity is one block,
> with data ordered it is one sector.

Imagine that you request a 2Mb write to an ext3 filesystem with an 1Mb
journal. There is *no way* the filesystem can do the write in an atomic
operation. (there would be if the filesystem wrote the data to free
blocks and updated the metadata through the journal)

The point is, there is no concept of "atomic operation" at the file
system level, so the application must do journaling itself if it wants
to have some concept of "transactions".

>From my experience with CF cards, there are some brands that do
wear-leveling (I know that at least the TwinMOS ones do, and probably
SanDisk too) and others that don't (Kingmax). 

With a bad CF card and an ext3 filesystem you can get bad sectors in a
couple of hours doing some intensive writing. 

A good CF card will sustain "normal use" (2 writes per minute average)
and an ext3 filesystem for months (maybe years, I still didn't went that
far in time :)

Just my two cents,

-- 
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"


  reply	other threads:[~2004-06-18 11:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <40FB8221D224C44393B0549DDB7A5CE83E31B1@tor.lokal.lan>
2004-06-15 18:09 ` mode data=journal in ext3. Is it safe to use? Petter Larsen
2004-06-15 18:20   ` Eugene Crosser
2004-06-17  8:36     ` Petter Larsen
2004-06-16  7:34   ` Oleg Drokin
2004-06-17  8:27     ` Petter Larsen
2004-06-17 17:09       ` Oleg Drokin
2004-06-18  9:41         ` Helge Hafting
2004-06-18 10:15           ` Oleg Drokin
2004-06-18 11:30             ` Paulo Marques [this message]
2004-06-18 12:05               ` Oleg Drokin
2004-06-21 17:42                 ` mode data=journal in ext3. Is it safe to use? Conclusion Petter Larsen
2004-06-19 19:16               ` mode data=journal in ext3. Is it safe to use? Bernd Eckenfels
2004-06-16 15:49   ` Timothy Miller
2004-06-17  0:51     ` Daniel Pittman
2004-06-17  3:02       ` Tim Connors
2004-06-17  5:35       ` Hans Reiser
2004-06-17 10:08         ` Dave Jones
2004-06-17 16:55           ` Hans Reiser
2004-06-17  8:29     ` Petter Larsen
2004-06-17 19:30       ` Daniel Egger
     [not found]       ` <87wu26mto2.fsf@enki.rimspace.net>
2004-06-27 14:17         ` Petter Larsen
2004-06-28  0:22           ` Daniel Pittman
     [not found]     ` <1805.216.148.213.196.1087426691.squirrel@www.code-visions.com>
2004-06-17 11:23       ` Petter Larsen
2004-06-17 16:26         ` Andreas Dilger
2004-06-17 14:56 Ken Ryan
2004-06-17 16:06 ` Timothy Miller
2004-06-17 17:20   ` Hans Reiser
2004-06-17 19:15     ` Ken Ryan
2004-06-18  6:18       ` Hans Reiser
2004-06-17 19:43     ` Daniel Egger
2004-06-17 19:59       ` Ken Ryan
2004-06-19 14:49 ` Petter Larsen

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=1087558255.25904.14.camel@pmarqueslinux \
    --to=pmarques@grupopie.com \
    --cc=ext3-users@redhat.com \
    --cc=green@linuxhacker.ru \
    --cc=helge.hafting@hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pla@morecom.no \
    /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