public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Kamil Kisiel <kamil@zymeworks.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS and block-level snapshots
Date: Tue, 10 Jun 2008 13:51:19 +1000	[thread overview]
Message-ID: <20080610035119.GY10720@disturbed> (raw)
In-Reply-To: <FCF761C7-435E-4AA5-9055-9DA0033B7ACC@zymeworks.com>

On Fri, Jun 06, 2008 at 11:33:17AM -0700, Kamil Kisiel wrote:
> Hello,
>
> I had a question about XFS integrity and performing block-level  
> snapshots.
>
> We currently have a 2TB (but growing soon..) volume mounted by a Linux  
> host with kernel 2.6.23 over iSCSI from our SAN. Our SAN unit has the  
> capability to perform block-level snapshots, which is done at regular  
> intervals.
>
> I know that it is recommended to perform an xfs_freeze before performing 
> a snapshot. However, the control of the snapshots is independent from the 
> OS, which currently has no knowledge of their occurrence. I'm curious as 
> to the repercussions of this. I understand that in all likelyhood, the 
> integrity of files which are currently being written will not be 
> preserved. However, even with an xfs_freeze this is not guaranteed, as an 
> application may require additional disk transactions to maintain the file 
> in a valid state (it is not necessarily atomic, depending on the 
> application).

That's from an application POV, not a filesystem POV. When you
freeze the filesystem all the data and metadata is guaranteed to be
consistent on disk. If your application requires further guarantees
of atomicity, then it needs to call xfs_freeze at a time that the
application can guarantee that it'sstate in the filesystem is
consistent.  i.e. not a filesystem problem.

> As far as metadata transactions are concerned, the journal should
> make  these atomic, so there should not be any problem there?

Sure, asssuming that at the time the snapshot is taken that the sum
of the journal contents, the filesystem metadata on disk and the
data on disk = a consistent filesystem image. Which, of course, will
never happen when you randomly snapshot a busy filesystem as it's a
constantly moving target.

e.g. say that while the log is being snapshotted by the block device
it wraps (i.e. the head moves from the end to the start) and
metadata I/O completes so the tail moves forward. now you have a
snapshot with the old tail in it and you've lost the transactions at
the head of the log. i.e. the journal is no longer consistent with
what is on disk in the snapshot. This can happen for data vs
metadata, metadata vs metadata and metadata vs log. IOWs, if you
don't freeze before you snapshot, your snapshot if full of nasty
little inconsistencies just waiting to trip you over....

> Basically, I'd like to know what is the worst that could happen, and why 
> an xfs_freeze is necessary in this scenario.

Worst case? Silent data corruption in the snapshot. Metadata
corruption in the snapshot leading to filesystem shutdowns and
system panics. Choose your poison - they're all bad.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2008-06-10  3:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06 18:33 XFS and block-level snapshots Kamil Kisiel
2008-06-10  3:51 ` Dave Chinner [this message]

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=20080610035119.GY10720@disturbed \
    --to=david@fromorbit.com \
    --cc=kamil@zymeworks.com \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox