From owner-freebsd-stable@FreeBSD.ORG Fri Apr 1 02:32:33 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 F0C2516A4CE for ; Fri, 1 Apr 2005 02:32:32 +0000 (GMT) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A32B943D39 for ; Fri, 1 Apr 2005 02:32:32 +0000 (GMT) (envelope-from dave_knight@isc.org) Received: from [204.152.189.43] (dhcp-wi-43.sql1.isc.org [204.152.189.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 7A33A67503 for ; Fri, 1 Apr 2005 02:32:32 +0000 (UTC) (envelope-from dave_knight@isc.org) Message-ID: <424CB2BB.1080709@isc.org> Date: Thu, 31 Mar 2005 18:32:27 -0800 From: Dave Knight Organization: Internet Systems Consortium, Inc. User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01A214813C6F537FD0F8DB34" Subject: Re: RELENG_5, snapshots and disk lock time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dave_knight@isc.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 02:32:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01A214813C6F537FD0F8DB34 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >On Mon, Mar 07, 2005 at 11:58:02AM -0500, Paul Mather wrote: >>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. >> :-( I am investigating using snapshots for backup purposes and am running into similar difficulties, on a 1TB FS it takes over an hour to create a snapshot, during which time an errant ls or two can lock up the system. Reading through list archives suggests that the the amount of time it takes to create the snapshot is not something that is going to go away and that the issue of an ls in the .snap directory during snapshot creation lacks a fix and that best current practise is 'try to avoid that'. > Yes, this is normal. See the documentation about the snapshots > implementation (a README in the kernel source tree, I think, and paper > written by Kirk). That document also says: "As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use." Is this the current opinion of snapshots ? >> 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. > > It's possible there are still deadlock conditions in the snapshot > code. Some familiarity with DDB would help to diagnose this (see the > chapter on kernel debugging in the developers' handbook). You'd need > to work with Kirk to debug these, if you're willing. > >> I wonder how much activity mksnap_ffs can take? > > I don't think this is the issue, directly. --------------enig01A214813C6F537FD0F8DB34 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTLLAfMm2ls5W1rkRAvllAKC9X2Q2TnZxgVLvLV+ZWer2CqwmXgCgqUo0 k3UASTDKJXggCUUzp7VEBjk= =zuGJ -----END PGP SIGNATURE----- --------------enig01A214813C6F537FD0F8DB34--