archive mirror
 help / color / mirror / Atom feed
From: "Andi Kleen" <>
To: Jos Visser <>
Cc: Paul Jakma <>, Michael Marxmeier <>,,,
Subject: Re: [linux-lvm] LVM 0.8final for 2.2.15/2.2.16?
Date: Thu, 8 Jun 2000 10:34:15 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>; from on Thu, Jun 08, 2000 at 10:23:21AM +0200

On Thu, Jun 08, 2000 at 10:23:21AM +0200, Jos Visser wrote:
> I have followed only part of this thread, but the gest I get is that
> people want to take an LVM snapshot of a file system, and the issue
> at hand is the status of the file system after the sync. I would like
> to make some remarks based on my experience with other volume managers
> and file systems. If all or most of this is already a piece of cake
> for you, please ignore it, but I reckon that there will be people
> on the list (or reading the archives) that will find this useful.
> 1) To be useful the snapshot must be "atomic", which means that the
>    snapshotted LV contains an image which conforms to the orginal at
>    a certain time. Since creating the snapshot usually involves some
>    copying of data blocks (to put it mildly) during which you do not
>    pause the entire system, a smart mechanism must be created to 
>    maintain this "illusion" of atomicity. 

The problem is that it is not enough to sync the file systems to
get an atomic copy; you must sync all applications too. For example
consider a database that uses user space journaling using fsync:
to make its disk files consistent after the snapshot it requires
both the log write and the data write. When one is missing the
log needs to be replayed, which requires writes.

>    The Veritas eXtended File System (vxfs) has a built-in snapshot
>    system which works kind-a interesting. Instead of doing a full
>    block device copy of the file system, it uses an "overflow"
>    block device where it saves the originals of a changed block
>    in the original block device. When looking at the snapshot, the
>    vxfs first checks the overflow area if a copy of the requested
>    block is available there. If it is, that block is returned, if
>    it isn't, the block is read from the underlying original since
>    it obviously hasn't been changed since the creation of the
>    snapshot (otherwise the original would have been present in the
>    overflow area). In the worst case the overflow area must be as
>    big as the original, but in typical cases it needs only be
>    10% of the size of the original. After system reboot, the
>    snapshot copy is gone.

This is basically how the current LVM snapshot mechanism works.  The 
overflow blocks are configurable.  The snapshots are gone after a reboot.

>    I would guess that such a volatile snapshot facility could be
>    made into a generic feature available for every block device!

Yes, it's called LVM @)

> 5) So, ideally we would need an "application quiesce" in which
>    we can instruct the application to update its ondisk image
>    by making all necessary changes to its disk data (flush()ing)
>    and informing the operating system of its quiesced state, 
>    upon which the OS could make the snapshot and free the
>    application to make changes again. Unix just does not support
>    this particular model of application/OS interaction. And,

There is an easy workaround: make the snapshots writeable and allow
an application ``fsck'' or log replay in the snapshot
(if it can't handle that it is not crash safe anyways)


  reply	other threads:[~2000-06-08  8:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2000-06-07 23:18 ` Paul Jakma
2020-11-27 16:17   ` Michael Marxmeier
2000-06-08  0:47     ` Paul Jakma
2000-06-08  8:23       ` Jos Visser
2000-06-08  8:34         ` Andi Kleen [this message]
2000-06-08 11:49           ` Paul Jakma
2000-06-08 12:34             ` Jos Visser
2000-06-09  6:59               ` Heinz J. Mauelshagen
2000-06-08  7:52     ` Heinz J. Mauelshagen
2000-06-06  9:51 Paul Jakma
2000-06-06 14:42 ` Andi Kleen
2000-06-06 22:30   ` Paul Jakma
2000-06-06 22:46     ` Andi Kleen
2000-06-07  0:03       ` Paul Jakma
2000-06-07  0:09       ` Paul Jakma
2000-06-12 13:20   ` Paul Jakma
2000-06-12 19:53     ` Jay Weber

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [linux-lvm] LVM 0.8final for 2.2.15/2.2.16?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).