Prev: Hauppauge HVR 2250 in Suse 11.1?
Next: scanners for use with Linux under the sane system
From: Trevor Hemsley on 14 Oct 2009 13:14
On Wed, 14 Oct 2009 13:21:15 UTC in comp.os.linux.hardware, Andrew Gideon
<c182driver1(a)gideon.org> wrote:

> Is this reliable?

No.

--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
From: David Brown on 15 Oct 2009 04:33
Andrew Gideon wrote:
> On Wed, 14 Oct 2009 09:00:13 +0200, David Brown wrote:
>
>> It can also side-step the fsck issue - you take a snapshot of the real
>> filesystem partition, and run an fsck on the snapshot. If the snapshot
>> fsck shows errors, you umount and repair the main partition - otherwise,
>> use tune2fs to set the "mount-count" to 0 so that the main partition
>> will not be checked automatically for a while yet.
>
> Is this reliable? I'd think that it would tend to cause "false
> positives" (that is, you'll see fsck failures on the snapshot that aren't
> really a problem).
>

It's not 100% reliable - as you say, you could get false positives
(i.e., a failed fsck while the "real" partition is actually fine).
Taking an LVM snapshot is much like doing an unexpected power cycle, so
it is quite possible to take the snapshot with the filesystem labelled
"dirty".

However, with a journalled filesystem, unexpected power cycles rarely
lead to corruption of the filesystem - and even then, it is often due to
hard disk write buffering (an issue you don't have with LVM snapshots).

So you may get a message telling you that the journal is being replayed
due to an unclean shutdown, but the fsck will probably be fine. And the
chances of that happening can be greatly reduced by doing a "sync"
before the snapshot. The standard practice of using "noatime" or
"relatime" on the main partition also helps avoid extra writes, and
therefore reduces the chance of the snapshot being unclean.

I can't think of any reason why you might get a false negative - that
the snapshot fsck is fine even though there is a problem on the real
partition.

> The reason I'd envision this is that an LVM snapshot operation is block
> level. If you take a snapshot when the file system is active, the file
> system may not be in a stable/quiescent state, resulting in complaints
> from fsck.
>
> I expect that, if you unmounted the volume before the snapshot, you'd
> resolve this problem. Is that a necessary step? Is there some other way
> to force a filesystem into a quiescent state during a block-level
> snapshot by LVM? Or is there something about this that I'm missing?
>

If absolute precision of the fsck is important, then you need to umount
the volume before the snapshot. You then have some "downtime" on the
partition, but it is a matter of seconds for the umount, snapshot, and
remount - the actual time-consuming fsck is still done on the snapshot
while the main partition is back in use.

What you are missing here is just the issue of probabilities. Yes,
there is a small chance of a false positive on the snapshot fsck even if
you've used "sync" before the snapshot. But you have to weigh that
against the alternative - time-consuming downtime for a real fsck on a
system that is probably fine in the first place.

Also, if you are unlucky enough to have a seriously corrupt filesystem,
running an fsck on a snapshot gives you the chance to test out
potentially dangerous fixes before running it on the main partition.

> - Andrew
From: DenverD on 15 Oct 2009 04:44
> How should I use a 1 TB hd?

isn't that kinda like asking: i responded to one of those net
advertisements selling methods of increasing one's "manhood", and now
i wanna know how i should use the monster?

must be a slow news day..huh?
--
DenverD (Linux Counter 282315) via Thunderbird 2.0.0.23 (20090817),
KDE 3.5.7 "release 72-11", openSUSE Linux 10.3, 2.6.22.19-0.4-default
#1 SMP i686 athlon
First  |  Prev  | 
Pages: 1 2 3
Prev: Hauppauge HVR 2250 in Suse 11.1?
Next: scanners for use with Linux under the sane system