[Top] [All Lists]

Summary - Snapshot Effort

To: xfs mailing list <linux-xfs@xxxxxxxxxxx>
Subject: Summary - Snapshot Effort
From: Greg Freemyer <freemyer@xxxxxxxxxxxxxxxxx>
Date: Thu, 22 Aug 2002 17:43:42 -0400
Cc: LVM Mailing list <linux-lvm@xxxxxxxxxxx>
Organization: The NorcrossGroup
Sender: owner-linux-xfs@xxxxxxxxxxx

I have not been successful at getting reliable Read-Only snapshots of XFS via 
LVM.  Since XFS is being used in Enterprise quality applications, I suggest 
this is a major shortcoming that should be prioritized.

BTW: Are there any snapshot related tests in the XFS regression tests?

Since my testing is based on XFS V1.1, this may have been resolved in XFS CVS 
code.  My responses from Dale Stephenson imply that there is little in the LVM 
CVS code that would address this.

I believe there is a bug in one of the two products, or more likely it is an 
integration issue between the two. 

( It would be great in my mind if the future XFS V1.2 release had a specific 
LVM configuration that reliably supported snapshots. )

Dale Stephenson has made some LVM related suggestions which I have not yet 
tried, but they appear more exotic than I am willing to try at the moment.
I thought I would summarize what I have attempted and then move on to other 

I am testing with the most recently release SuSE kernel based on 2.4.19pre1aa1. 
 Apparently this uses the XFS V1.1 patches.

This kernel does have the VFS-lock patch recommended by Adrian Head included.  
(I don't know if it is in the base kernel, or if Andrea or SuSE put it in 

First with no i/o load, or read-only load I have had no problems.

With a heavy read/write load of the xfs filesystem induced with a simple dd 
command, I have not been able to repeatably create a snapshot.

I have never had as many as 20 consecutive successful attempts.  My latest test 
had a 60 minute sleep between the lvremove and the lvcreate --snapshot.  (This 
was in the hope that the LVM needed time to completely remove the previous 
snapshot before the new one could be created.) 

When a failure occurs the lvcreate --snapshot command will freeze up.    

A manually entered xfs_freeze -u will release the lvcreate.  (The VFS-lock 
patch effectively is calling xfs_freeze -f internally prior to starting the 
snapshot process.)

Obviously, if a xfs_freeze -u is required to allow lvcreate --snapshot to 
complete, there is the small chance of ending up with a non-mountable snapshot. 
 At least one of my tests had this result.

FYI: Adrian Head believes that the VFS-lock patch is more reliable than not 
having it and wrapping the lvcreate --snapshot call with explicit xfs_freeze 
calls.  I have not tried that.

There are a set of LVM kernel patches to help with this lockup available from 
Dale Stephenson, but he describes them as "an ugly hack that works most of the 
not the sort of thing you want in a CVS tree."

Since I am trying to test a system for production deployment, this was enough 
to scare me away.

An alternative solution from Dale:

>> One way that should not experience lockups is to use neither
>> xfs_freeze nor the VFS lock patch, but use writable snapshots.
>> The snapshot won't be a consistent filesystem, but mount it with
>> the nouuid option and let it do recovery. This way may not give
>> you what you wanted, but at least it won't lock up.

I am considering this option, but it does not sound optimal to me.

One more FYI: How to know if your kernel has the VFS lock patch.

Explicitly call xfs_freeze -f to freeze the filesystem, then lvcreate to create 
a snapshot. Assuming the lvcreate runs to completion, check the
original filesystem and see if it is now unfroze.

If the filesystem is unfrozen, you have the patch.

If it is still frozen, you don't have the patch.

Hope someone finds that informative,
Greg Freemyer
Internet Engineer
Deployment and Integration Specialist
Compaq ASE - Tru64 v4, v5
Compaq Master ASE - SAN Architect
The Norcross Group

<Prev in Thread] Current Thread [Next in Thread>