Date: Thu, 11 Jan 2007 16:48:06 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Scott Oertel <freebsd@scottevil.com> Cc: Willem Jan Withagen <wjw@digiware.nl>, freebsd-stable@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: running mksnap_ffs Message-ID: <20070111214806.GA37942@xor.obsecurity.org> In-Reply-To: <45A6AEBC.800@scottevil.com> References: <459ABB40.7050603@digiware.nl> <20070111153651.GC31382@xor.obsecurity.org> <45A68F2E.6040205@scottevil.com> <20070111200152.GA36123@xor.obsecurity.org> <45A6AEBC.800@scottevil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070111214806.GA37942>