lkml.org 
[lkml]   [2004]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Desktop Filesystem Benchmarks in 2.6.3
Hi!

> It would be nice if someone with more profound knowledge could comment
> on this, but my understanding of the problem is:
>
> - journaled filesystems can only work when they can enforce that
> journal data is written to the platters at specifc times wrt
> normal data writes
> - IDE write caching makes the disk "lie" to the kernel, i.e. it says
> "I've written the data" when it was only put in the cache
> - now if a *power failure* keeps the disk from writing the cache
> contents to the platter, the fs and journal are inconsistent
> (a kernel crash would not cause this problem because the disk can
> still write the cache contents to the platters)
> - at next mount time the fs will read the journal from the disk
> and try to use it to bring the fs into a consistent state;
> however, since the journal on disk is not guaranteed to be up to date
> this can *fail* (I have no idea what various fs implementations do
> to handle this; I suspect they at least refuse to mount and require
> you to manually run fsck. Or they don't notice and let you work
> with a corrupt filesystem until they blow up.)
>
> Right? Or is this just paranoia?

Twice a year I fsck my reiser drives, and yes there's some corruption there.
So you are right, and its not paranoia.

--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.418 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site