All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: linux-lvm@sistina.com
Subject: RE: [linux-lvm] snapshots of busy ext2 file system corrupt
Date: Wed Feb 27 14:43:03 2002	[thread overview]
Message-ID: <3303790000.1014842549@tiny> (raw)
In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F0C6@cdserv.meridian-data.com>


On Wednesday, February 27, 2002 12:27:00 PM -0800 "Stephenson, Dale" <dstephenson@snapserver.com> wrote:

> Anselm Kruis writes:
> 
> [Of the VFS lock patch]
>> 
>> It deadlocks for XFS on smp under heavy writeload. I use a writeable
>> snapshot patch and replay the log afterwards.
>> 
> So if you don't have the patch, you don't have a deadlock?  I've been trying
> to track down a problem with multiple snapshots of the same volume, but the
> presence or absence of the lock patch doesn't seem to make a difference.

The slow part is in fsync_dev (and fsync_dev_lockfs), where we call
sync_buffers(dev, 0).  If there is heavy FS traffic, the buffer list
keeps refilling.

The whole thing would be much faster if the sync_buffers(dev, 0) call
were moved after the lockfs call, but that would require the filesystem
to be able to start buffer writes while the FS was locked.

For all the in-kernel filesystems, this is not a problem, but I was
assuming XFS was going to do strange things during the sync_buffers
call.
 
> 
>> I think, the VFS patch has some principal problems. Creating 
>> a snapshot
>> with the VFS-lock patch applied is more or less equivalent to 
>> unmounting 
>> the file system, creating the snapshot of the device and 
>> remounting the
>> file system. That means that all ongoing write operations must be
>> suspended until the filesystem is in a "clean" state. This can take
>> some time. Up to 15 minutes from my observations and that is 
>> way too long.
>> I think the right way is: use a jornaling file system, take a 
>> snapshot,
>> make the snapshot writeable, replay the log, make the 
>> snapshot readonly
>> and dump it to tape or whatever you want. No races, no deadlocks, no
>> problems.

There is a problem with this method, namely the FS you get after
replaying the log will not be the same FS you had at the time of
the snapshot.  Any transactions that had not been committed yet will
not be replayed.  It will be consistent, but probably not the FS you
were expecting.

-chris

  reply	other threads:[~2002-02-27 14:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-27 14:24 [linux-lvm] snapshots of busy ext2 file system corrupt Stephenson, Dale
2002-02-27 14:43 ` Chris Mason [this message]
2002-03-04  2:46   ` Anselm Kruis
2002-03-04  2:51 ` Anselm Kruis
  -- strict thread matches above, loose matches on Subject: below --
2002-02-26  7:55 Urs Thuermann
2002-02-26 10:59 ` Andreas Dilger
2002-02-26 11:40   ` Chris Mason
2002-02-26 13:30     ` Urs Thuermann
2002-02-26 14:58       ` Chris Mason
2002-02-26 15:27         ` Andreas Dilger
2002-02-26 16:32           ` Marc MERLIN
2002-02-26 17:21             ` Andreas Dilger
2002-02-26 13:25   ` Urs Thuermann
2002-02-27  3:01 ` Anselm Kruis

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=3303790000.1014842549@tiny \
    --to=mason@suse.com \
    --cc=linux-lvm@sistina.com \
    /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.