From owner-freebsd-stable@FreeBSD.ORG Mon Mar 7 16:58:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F1D116A4CF for ; Mon, 7 Mar 2005 16:58:11 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E377D43D41 for ; Mon, 7 Mar 2005 16:58:10 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-89-235.roa.east.verizon.net [151.199.89.235]) by gromit.dlib.vt.edu (8.13.1/8.13.1) with ESMTP id j27Gw9iJ040950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2005 11:58:10 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3) with ESMTP id j27Gw3g7069922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Mar 2005 11:58:03 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.3/8.13.3/Submit) id j27Gw3Ng069921; Mon, 7 Mar 2005 11:58:03 -0500 (EST) (envelope-from paul@gromit.dlib.vt.edu) X-Authentication-Warning: zappa.Chelsea-Ct.Org: paul set sender to paul@gromit.dlib.vt.edu using -f From: Paul Mather To: Dmitry Morozovsky In-Reply-To: <20050307151733.I4264@woozle.rinet.ru> References: <20050307151733.I4264@woozle.rinet.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 07 Mar 2005 11:58:02 -0500 Message-Id: <1110214682.63484.9.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port cc: freebsd-stable@freebsd.org Subject: Re: RELENG_5, snapshots and disk lock time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2005 16:58:11 -0000 On Mon, 2005-03-07 at 15:21 +0300, Dmitry Morozovsky wrote: > Dear colleagues, > > dumping the snapshot of 140G ufs2 fyle system under contemporary RELENG_5 I > found that during mksnap_ffs file system is unresponsible even for reading for > more than 3 minutes (it's on modern SATA disk with 50+ MBps linear transfer). > Is it normal? Oddly enough, this happened to me last night on a RELENG_5 system. In my case, things were so bad that mksnap_ffs appeared to wedge everything, meaning I'll have to make a trek in to where the machine is located and press the ol' reset button to get things going again. :-( The machine in question makes and mounts snapshots of all its filesystems for backup each night via Tivoli TSM. This has worked flawlessly for many months. Last night, I had many BitTorrent sessions active on the filesystem that wedged. I guess the activity broke the snapshot mechanism. :-( The odd thing is that it survived the night before, when there were also BitTorrent sessions active. I wonder how much activity mksnap_ffs can take? Cheers, Paul. PS: The problematic file system was not low on space, which could be an issue for snapshot creation. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa