[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <B18BA4E1-2D18-4E00-8678-5DE92EBA343D@sun.com>
Date: Mon, 09 Nov 2009 08:58:49 -0700
From: Andreas Dilger <adilger@....com>
To: Theodore Tso <tytso@....edu>
Cc: Pavel Machek <pavel@....cz>, david@...g.hm,
Rik van Riel <riel@...hat.com>,
Ric Wheeler <rwheeler@...hat.com>,
Florian Weimer <fweimer@....de>,
Goswin von Brederlow <goswin-v-b@....de>,
Rob Landley <rob@...dley.net>,
kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
rdunlap@...otime.net, linux-doc@...r.kernel.org,
ext4 development <linux-ext4@...r.kernel.org>, corbet@....net,
Jan Kara <jack@...e.cz>,
Bryan Kadzban <bryan@...zban.is-a-geek.net>,
Karel Zak <kzak@...hat.com>,
LVM Mailing List <linux-lvm@...hat.com>
Subject: Re: periodic fsck was Re: [patch] ext2/3: document conditions when
reliable operation is possible
On 2009-11-09, at 07:05, Theodore Tso wrote:
> So these days, what I strongly recommend is that people use LVM
> snapshots, and schedule weekly checks during some low usage period
> (i.e., 3am on Saturdays), using something like the e2croncheck shell
> script.
There was another script written to do this that handled the e2fsck,
reiserfsck
and xfs_check, detecting all volume groups automatically, along with
e.g.
validating that the snapshot volume doesn't exist before starting the
check
(which may indicate that the previous e2fsck is still running), and
not running while on AC power.
The last version was in the thread "forced fsck (again?)" dated
2008-01-28.
Would it be better to use that one? In that thread we discussed not
clobbering
the last checked time as e2croncheck does, so the admin can see how
long it
was since the filesystem was last checked.
Maybe it makes more sense to get the lvcheck script included into util-
linux-ng
or lvm2 packages, and have it added automatically to the cron.weekly
directory?
Then the distros could disable the at-boot checking safely, while
still being
able to detect corruption caused by cables/RAM/drives/software.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists