From owner-freebsd-questions@FreeBSD.ORG Wed Mar 30 14:16:28 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B8EB16A4CE for ; Wed, 30 Mar 2005 14:16:28 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FBE43D5C for ; Wed, 30 Mar 2005 14:16:28 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0B26D511F4; Wed, 30 Mar 2005 06:16:27 -0800 (PST) Date: Wed, 30 Mar 2005 06:16:26 -0800 From: Kris Kennaway To: Andrea Venturoli Message-ID: <20050330141626.GB73682@xor.obsecurity.org> References: <424AACD1.3060802@netfence.it> <20050330134259.GA66640@xor.obsecurity.org> <424ACEF8.60601@netfence.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <424ACEF8.60601@netfence.it> User-Agent: Mutt/1.4.2.1i cc: freebsd-questions@freebsd.org cc: Kris Kennaway Subject: Re: mksnap_ffs woes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 14:16:28 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2005 at 05:08:24PM +0100, Andrea Venturoli wrote: > Kris Kennaway wrote: >=20 > >mksnap_ffs may sometimes take a long time (order of tens of minutes) > >to generate the snapshot. During this time, other writes to the > >filesystem may be suspended. Are you sure this isn't what you're > >seeing? >=20 > I am not sure, but I don't think so. >=20 > First of all, while I would not expect an exactly deterministic=20 > behaviour, I still find it strange that most of the times it works=20 > within seconds, and occasionally it might need so long! Then again, I do= =20 > not have enough insight to explain why it would or why it shouldn't. It's possible you're seeing deadlock bugs in the snapshot code; you'd need to compile your system with DDB support and obtain traceback information as described in the developers' handbook chapter on kernel debugging. > Lastly, if what you say is true, that "writes to the filesytem may be=20 > suspended" for that long, then I don't see much point in using this=20 > feature. At least, it is not one that suits *my* needs: our clients must= =20 > be up 24/7; if that happens they will time out and someone will need to= =20 > go there and powercycle them. The snapshot code was intended to support background fsck and that alone. It's also optionally used by the dump code, but it was not written as a general-purpose live filesystem snapshot service. > Am I going in the wrong direction then? > Are there other alternatives for live backups? Plenty, if you don't demand an instantaneous image of the backup image. > Is there some sort of more detailed documentation (tutorials, howtos,=20 > ...) on this topic? The pros and cons of the snapshot code have been discussed on the mailing lists, and there is a (slightly outdated) information file here: /usr/src/sys/ufs/ffs/README.snapshot Kris --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCSrS6Wry0BWjoQKURApazAJ9q9D562ygA6L9HrDMJkG0YgGbzzACdGQdJ 7gU8/2dKSsMgjdhXVSddfZw= =xQ8J -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t--