On Wed, Mar 30, 2005 at 05:08:24PM +0100, Andrea Venturoli wrote: > Kris Kennaway wrote: > > >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? > > I am not sure, but I don't think so. > > First of all, while I would not expect an exactly deterministic > behaviour, I still find it strange that most of the times it works > within seconds, and occasionally it might need so long! Then again, I do > 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 > suspended" for that long, then I don't see much point in using this > feature. At least, it is not one that suits *my* needs: our clients must > be up 24/7; if that happens they will time out and someone will need to > 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, > ...) 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
pgpDhB7lK4kjv.pgp
Description: PGP signature