Date: Wed, 30 Mar 2005 06:16:26 -0800 From: Kris Kennaway <kris@obsecurity.org> To: Andrea Venturoli <ml.diespammer@netfence.it> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: mksnap_ffs woes Message-ID: <20050330141626.GB73682@xor.obsecurity.org> In-Reply-To: <424ACEF8.60601@netfence.it> References: <424AACD1.3060802@netfence.it> <20050330134259.GA66640@xor.obsecurity.org> <424ACEF8.60601@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050330141626.GB73682>