Date: Wed, 6 Sep 2006 11:58:21 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Philippe Pegon <Philippe.Pegon@crc.u-strasbg.fr> Cc: stable@freebsd.org, Ulrich Sp?rlein <ulrich.spoerlein@1822direkt.com> Subject: Re: Snapshot duration, performance and how to avoid I/O lock Message-ID: <20060906155821.GB18415@xor.obsecurity.org> In-Reply-To: <44FED689.8070202@crc.u-strasbg.fr> References: <239947161@misc1.1822direkt.com> <44FED689.8070202@crc.u-strasbg.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE/vAdWry0BWjoQKURAsKLAJ4itt07S7EAEaxPesshl8XsiW5EtACg3STH a77d9h4ljI6sKfV+jwFAbME= =C/Oe -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060906155821.GB18415>