From owner-freebsd-questions@FreeBSD.ORG Wed Mar 30 14:08:33 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 D401F16A4CE for ; Wed, 30 Mar 2005 14:08:33 +0000 (GMT) Received: from parrot.aev.net (host29-15.pool8174.interbusiness.it [81.74.15.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 991FC43D46 for ; Wed, 30 Mar 2005 14:08:32 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-223-56.38-151.net24.it [151.38.56.223]) (authenticated bits=128) by parrot.aev.net (8.13.1/8.13.1) with ESMTP id j2UEScHU024691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Mar 2005 16:28:45 +0200 (CEST) (envelope-from ml.diespammer@netfence.it) Received: from netfence.it (xanatar.ventu [10.1.2.6]) (authenticated bits=0) by soth.ventu (8.13.3/8.13.1) with ESMTP id j2UE8LHS070573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2005 16:08:21 +0200 (CEST) (envelope-from ml.diespammer@netfence.it) Message-ID: <424ACEF8.60601@netfence.it> Date: Wed, 30 Mar 2005 17:08:24 +0100 From: Andrea Venturoli Organization: NetFence User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: it,en,fr,de MIME-Version: 1.0 To: Kris Kennaway References: <424AACD1.3060802@netfence.it> <20050330134259.GA66640@xor.obsecurity.org> In-Reply-To: <20050330134259.GA66640@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 cc: freebsd-questions@freebsd.org 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:08:33 -0000 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. I didn't always have the opportunity to check, but I did once: I'm sure the disks were not working, and the CPU was not under stress, so I can see no reason why it would take that long (I waited for more than an hour, then decided to reset). 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. Am I going in the wrong direction then? Are there other alternatives for live backups? Is there some sort of more detailed documentation (tutorials, howtos, ...) on this topic? bye & Thanks av.