From owner-freebsd-stable@FreeBSD.ORG Thu Jan 11 21:48:08 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D60C16A494 for ; Thu, 11 Jan 2007 21:48:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 80D1B13C442 for ; Thu, 11 Jan 2007 21:48:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0DF3C1A3C1A; Thu, 11 Jan 2007 13:48:08 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 41050516AC; Thu, 11 Jan 2007 16:48:06 -0500 (EST) Date: Thu, 11 Jan 2007 16:48:06 -0500 From: Kris Kennaway To: Scott Oertel Message-ID: <20070111214806.GA37942@xor.obsecurity.org> References: <459ABB40.7050603@digiware.nl> <20070111153651.GC31382@xor.obsecurity.org> <45A68F2E.6040205@scottevil.com> <20070111200152.GA36123@xor.obsecurity.org> <45A6AEBC.800@scottevil.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <45A6AEBC.800@scottevil.com> User-Agent: Mutt/1.4.2.2i Cc: Willem Jan Withagen , freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: running mksnap_ffs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 21:48:08 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2007 at 01:40:12PM -0800, Scott Oertel wrote: > Kris Kennaway wrote: > >On Thu, Jan 11, 2007 at 11:25:34AM -0800, Scott Oertel wrote: > > =20 > >>Kris Kennaway wrote: > >> =20 > >>>On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote: > >>>=20 > >>> =20 > >>>>Hi, > >>>> > >>>>I got the following Filesystem: > >>>>Filesystem Size Used Avail Capacity iused ifree %iused=20 > >>>>/dev/da0a 1.3T 422G 823G 34% 565952 182833470 0% > >>>> > >>>>Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. > >>>>The system is used as SMB/NFS server for my other systems here. > >>>> > >>>>I would like to make weekly snapshots, but manually running mksnap_ff= s=20 > >>>>freezes access to the disk (I sort of expected that) but the process= =20 > >>>>never terminates. So I let is sit overnight, but looking a gstat did= =20 > >>>>not reveil any activity what so ever... > >>>>The disk was not released, mksnap_ffs could not be terminated. > >>>>And things resulted in me rebooting the system. > >>>> > >>>>So: > >>>>- How long should I expect making a snapshot to take: > >>>> 5, 15, 30min, 1, 2 hour or even more??? > >>>> =20 > >>>> =20 > >>>Yes :) Snapshots were not designed for use in this way (they were > >>>designed to support background fsck and allow faster system recovery > >>>after power failure), so they don't scale as well as you might like on > >>>large filesystems. > >>> > >>>Kris > >>>=20 > >>> =20 > >>If snapshots were designed to support background fsck, then why did the= y=20 > >>not make it more scalable? If you can't create a snapshot without the= =20 > >>system locking up, that means fsck won't be able to either, making=20 > >>background fsck worthless for systems with large storage. > >> =20 > > > >locking up !=3D taking a long time to complete. You haven't > >differentiated between those two situations yet. > > > >Kris > > =20 >=20 >=20 > It depends, sometimes it just takes a really long time during which the= =20 > system is unresponsive and unstable, or it just completely locks up.=20 > Does it make that much of a difference? in either case, snapshotting=20 > large drives is not very efficient, and can't be considered for=20 > background fsck, or daily backup. Which are the two main purposes of=20 > snapshots. Those are completely different situations, as I have tried to emphasize. If you are interested in proceeding to debug the deadlock issue, please follow the directions in the developers handbook chapter on kernel debugging (in particular obtain 'show lockedvnods' output with DEBUG_VFS_LOCKS and DEBUG_LOCKS enabled). kris --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) iD8DBQFFprCVWry0BWjoQKURAi4KAJ99WtTy0AWvqgrmvTq9D8cXyQvh2wCg1cc8 t8GlvN8J+beevkMHqlQkxr0= =ggDc -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--