Snapshot duration, performance and how to avoid I/O lock

[Kris Kennaway]

On Wed, Sep 06, 2006 at 04:09:13PM +0200, Philippe Pegon wrote:
> Ulrich Sp?rlein wrote:
> >Hi,
> 
> Hi,
> 
> >I have to create regular snapshots of several volumes roughly 1.4TB in 
> >size (each). But using mksnap_ffs takes a lot of time (45 minutes) and
> >it looks like it could be speed up.
> [snip]
> >Another thing is blocking other disk I/O while snapshotting. Right now I 
> >did
> >a ls(1) in the .snap directory, so I understand the filesystem is now 
> >suspended.
> >The workaround would then be to "dont do that". But what if other 
> >snapshots are
> >accessed during that time? I want to provide yesterdays snapshot to our 
> >users
> >while taking the current snapshot and providing access to the newest data 
> >at the
> >same time.
> 
> I had seen that a long time ago (on another controller), and it seems it's
> not better today

It's part of the design of the present UFS snapshots, for better or
worse.  You can work around the problem a bit more by creating the
snapshot in a subdirectory another level down
(e.g. /usr/.snap/.snap/), since this will avoid blocking unless you
recurse into /usr/.snap itself.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060906/157e0d1a/attachment.pgp