All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Otto Wyss <otto.wyss@orpatec.ch>
Cc: "'linux-kernel'" <linux-kernel@vger.kernel.org>
Subject: Re: New concept of ext3 disk checks
Date: Thu, 12 Aug 2004 18:39:07 -0400	[thread overview]
Message-ID: <20040812223907.GA7720@thunk.org> (raw)
In-Reply-To: <411BAFCA.92217D16@orpatec.ch>

On Thu, Aug 12, 2004 at 07:58:33PM +0200, Otto Wyss 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):

1) Create a clean, read-only snapshot of an ext3 filesystem using
device mapper.

2) Run e2fsck -f on the snapshot, and check to see if there are any
error on the filesystem.  Assuming a non-buggy kernel and properly
functioning hardware, there should be none.  Afterwards, release the
read-only snapshot.

3) If there are any errors, e-mail the output of e2fsck to the system
administrator.

4) If there were no errors detecting by the fsck run, run the command
"tune2fs -C 0 -T now /dev/XXX" on the live filesystem.  This sets the
mount count and last filesystem checked time to the appropriate values
in the superblock.

Tell you what --- if someone is willing to put the time into
developing such a script, I'll include it in the contrib section of
e2fsprogs.  I've put all the hooks to do this in e2fsprogs, and I've
wanted this for quite some time, but the last time I looked at it, the
command-line EVMS tools were truly gruesome to behold/use.  I believe
things have gotten much better since then, so this shouldn't be too
hard to do now.

					- Ted

  parent reply	other threads:[~2004-08-12 22:39 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 [this message]
2004-08-12 23:55   ` Bernd Eckenfels
2004-08-13  0:34   ` Andreas Dilger
2004-08-14  7:15     ` Otto Wyss
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=20040812223907.GA7720@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=otto.wyss@orpatec.ch \
    /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.