LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Szabolcs Szakacsits <szaka@ntfs-3g.org>
To: Daniel Phillips <phillips@google.com>
Cc: Pavel Machek <pavel@ucw.cz>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Theodore Tso <tytso@mit.edu>, Al Boldi <a1426z@gawab.com>,
Valerie Henson <val.henson@gmail.com>,
Rik van Riel <riel@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)
Date: Thu, 17 Jan 2008 14:29:47 +0200 (EET) [thread overview]
Message-ID: <Pine.LNX.4.62.0801171130560.12451@tamago.serverit.net> (raw)
In-Reply-To: <4d47a5d10801151744t378ecdcbj1c326181b4360452@mail.gmail.com>
On Tue, 15 Jan 2008, Daniel Phillips wrote:
> Along with this effort, could you let me know if the world actually
> cares about online fsck? Now we know how to do it I think, but is it
> worth the effort.
Most users seem to care deeply about "things just work". Here is why
ntfs-3g also took the online fsck path some time ago.
NTFS support had a highly bad reputation on Linux thus the new code was
written with rigid sanity checks and extensive automatic, regression
testing. One of the consequences is that we're detecting way too many
inconsistencies left behind by the Windows and other NTFS drivers,
hardware faults, device drivers.
To better utilize the non-existing developer resources, it was obvious to
suggest the already existing Windows fsck (chkdsk) in such cases. Simple
and safe as most people like us would think who never used Windows.
However years of experience shows that depending on several factors chkdsk
may start or not, may report the real problems or not, but on the other
hand it may report bogus issues, it may run long or just forever, and it
may even remove completely valid files. So one could perhaps even consider
suggestions to run chkdsk a call to play Russian roulette.
Thankfully NTFS has some level of metadata redundancy with signatures and
weak "checksums" which make possible to correct some common and obvious
corruptions on the fly.
Similarly to ZFS, Windows Server 2008 also has self-healing NTFS:
http://technet2.microsoft.com/windowsserver2008/en/library/6f883d0d-3668-4e15-b7ad-4df0f6e6805d1033.mspx?mfr=true
Szaka
--
NTFS-3G: http://ntfs-3g.org
next prev parent reply other threads:[~2008-01-17 13:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 21:22 [RFD] Incremental fsck Al Boldi
2008-01-08 21:31 ` Alan
2008-01-09 9:16 ` Andreas Dilger
2008-01-12 23:55 ` Daniel Phillips
2008-01-08 21:41 ` Rik van Riel
2008-01-09 4:40 ` Al Boldi
2008-01-09 7:45 ` Valerie Henson
2008-01-09 11:52 ` Al Boldi
2008-01-09 14:44 ` Rik van Riel
2008-01-10 13:26 ` Al Boldi
2008-01-12 14:51 ` Theodore Tso
2008-01-13 11:05 ` Al Boldi
2008-01-13 17:19 ` Pavel Machek
2008-01-13 17:41 ` Alan Cox
2008-01-15 20:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Pavel Machek
2008-01-15 21:43 ` David Chinner
2008-01-15 23:07 ` Pavel Machek
2008-01-15 23:44 ` Daniel Phillips
2008-01-16 0:15 ` Alan Cox
2008-01-16 1:24 ` Daniel Phillips
2008-01-16 1:36 ` Chris Mason
2008-01-17 20:54 ` Pavel Machek
2008-01-16 19:06 ` Bryan Henderson
2008-01-16 20:05 ` Alan Cox
2008-01-17 2:02 ` Daniel Phillips
2008-01-17 21:37 ` Bryan Henderson
2008-01-17 22:45 ` Theodore Tso
2008-01-17 22:58 ` Alan Cox
2008-01-17 23:18 ` Ric Wheeler
2008-01-18 0:31 ` Bryan Henderson
2008-01-18 14:23 ` Theodore Tso
2008-01-18 15:16 ` [Patch] document ext3 requirements (was Re: [RFD] Incrementalfsck) linux-os (Dick Johnson)
2008-01-19 14:53 ` Pavel Machek
2008-01-18 15:26 ` [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck) Ric Wheeler
2008-01-18 20:34 ` Jeff Garzik
2008-01-18 22:35 ` Bryan Henderson
2008-01-18 15:08 ` H. Peter Anvin
2008-01-18 17:43 ` Bryan Henderson
2008-01-16 21:28 ` Eric Sandeen
2008-01-16 11:51 ` Pavel Machek
2008-01-16 12:20 ` Valdis.Kletnieks
2008-01-19 14:51 ` Pavel Machek
2008-01-16 16:38 ` Christoph Hellwig
2008-01-16 1:44 ` Daniel Phillips
2008-01-16 3:05 ` Rik van Riel
2008-01-17 7:38 ` Andreas Dilger
2008-01-16 11:49 ` Pavel Machek
2008-01-16 20:52 ` Valerie Henson
2008-01-17 12:29 ` Szabolcs Szakacsits [this message]
2008-01-17 22:51 ` Daniel Phillips
2008-01-15 1:04 ` [RFD] Incremental fsck Ric Wheeler
2008-01-14 0:22 ` Daniel Phillips
2008-01-09 8:04 ` Valdis.Kletnieks
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=Pine.LNX.4.62.0801171130560.12451@tamago.serverit.net \
--to=szaka@ntfs-3g.org \
--cc=a1426z@gawab.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=phillips@google.com \
--cc=riel@redhat.com \
--cc=tytso@mit.edu \
--cc=val.henson@gmail.com \
--subject='Re: [Patch] document ext3 requirements (was Re: [RFD] Incremental fsck)' \
/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
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).