From: Otto Wyss <otto.wyss@orpatec.ch>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
"'linux-kernel'" <linux-kernel@vger.kernel.org>
Subject: Re: New concept of ext3 disk checks
Date: Sat, 14 Aug 2004 09:15:24 +0200 [thread overview]
Message-ID: <411DBC0C.7FE46F9C@orpatec.ch> (raw)
In-Reply-To: 20040813003403.GK18216@schnapps.adilger.int
On Aug 12, 2004 18:39 -0400, Theodore Ts'o wrote:
> > - Instead of checks forced during startup checks are done during runtime
> > (at low priority). It has to be determined if these checks are _only_
> > checks or if they also include possible fixes. Possible solution might
> > distinct between the severity of any discovered problem.
>
> This is something that doesn't require any kernel patches, or any
> other C coding for that matter, so it would be a great first project
> for someone who wanted to learn how to use the device-mapper snapshot
> feature. Basically, what you do is the following in a shell script
> which is fired off by cron once a week at 3am (or some other
> appropriate time):
Instead of a daily cron job I envision a solution where writes to the
disk are checked for correctness within a short time lag after they have
been done. Assume this time lag is set to a few minutes, on a high
performance system not each write of a certain node gets checked while
on a desktop system most probably each single write is. Choosing the
right time lag gives a balance of discovering problems fast against
additional disk access.
Okay, such tests could be done by a constantly running background task
in user space. But since journalling just should guarantee that any disk
access is done correct, even in case of problems, it should be
considered if such test can be integrated there. This has the advantage
that if journalling is able to guarantee correctness by other means
these test aren't needed at all and may be completely remove.
What I want to achieve with this new concept is that the file system
itself not only tries to prevent any data corruption but also tries to
detect and report it if corruption still has happened anyway.
O. Wyss
--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"
next prev parent reply other threads:[~2004-08-14 7:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 17:58 New concept of ext3 disk checks Otto Wyss
2004-08-12 18:58 ` Bernd Eckenfels
2004-08-12 21:07 ` Lee Revell
2004-08-12 19:46 ` Alan Cox
2004-08-14 7:26 ` Otto Wyss
2004-08-12 22:39 ` Theodore Ts'o
2004-08-12 23:55 ` Bernd Eckenfels
2004-08-13 0:34 ` Andreas Dilger
2004-08-14 7:15 ` Otto Wyss [this message]
2004-08-15 0:23 ` Andreas Dilger
[not found] <2ssbz-jB-1@gated-at.bofh.it>
[not found] ` <2swyz-3ny-13@gated-at.bofh.it>
2004-08-12 23:24 ` Andi Kleen
2004-08-12 23:48 ` Theodore Ts'o
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=411DBC0C.7FE46F9C@orpatec.ch \
--to=otto.wyss@orpatec.ch \
--cc=adilger@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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