From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 17 12:43:30 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7207816A418 for ; Wed, 17 Oct 2007 12:43:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 168D513C480 for ; Wed, 17 Oct 2007 12:43:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ii5ul-00099W-P0; Wed, 17 Oct 2007 13:14:11 +0300 Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ii5uj-000Ii5-UX; Wed, 17 Oct 2007 13:14:11 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l9HAE0WS024066; Wed, 17 Oct 2007 13:14:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l9HAE07V024065; Wed, 17 Oct 2007 13:14:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Oct 2007 13:14:00 +0300 From: Kostik Belousov To: Peter Jeremy Message-ID: <20071017101400.GH6511@deviant.kiev.zoral.com.ua> References: <20071016113046.GA35318@eos.sc1.parodius.com> <4714A663.5010800@freebsd.org> <20071017100003.GK1191@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAgJxtfIS94j9H4T" Content-Disposition: inline In-Reply-To: <20071017100003.GK1191@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: fa1e9f04260dd27375e84b1224048298 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1629 [Oct 16 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem snapshots dog slow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 12:43:30 -0000 --uAgJxtfIS94j9H4T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 17, 2007 at 08:00:03PM +1000, Peter Jeremy wrote: > On 2007-Oct-16 06:54:11 -0500, Eric Anderson wrote: > >will give you a good understanding of what the issue is. Essentially, yo= ur=20 > >disk is hammered making copies of all the cylinder groups, skipping thos= e=20 > >that are 'busy', and coming back to them later. On a 200Gb disk, you cou= ld=20 > >have 1000 cylinder groups, each having to be locked, copied, unlocked, a= nd=20 > >then checked again for any subsequent changes. The stalls you see are w= hen=20 > >there are lock contentions, or disk IO issues. On a single disk (like y= our=20 > >setup above), your snapshots will take forever since there is very littl= e=20 > >random IO performance available to you. >=20 > That said, there is a fair amount of scope available for improving > both the creation and deletion performance. >=20 > Firstly, it's not clear to me that having more than a few hundred CGs > has any real benefits. There was a massive gain in moving from > (effectively) a single CG in pre-FFS to a few dozen CGs in FFS as it > was first introduced. Modern disks are roughly 5 orders of magnitude > larger and voice-coil actuators mean that seek times are almost > independent of distance. CG sizes are currently limited by the > requirement that the cylinder group (including cylinder group maps) > must fit into a single FS block. Removing this restriction would > allow CGs to be much larger. >=20 > Secondly, all the I/O during both snapshot creation and deletion is > in FS-block size chunks. Increasing the I/O size would significantly > increase the I/O performance. Whilst it doesn't make sense to read > more than you need, there still appears to be plenty of scope to > combine writes. >=20 > Between these two items, I would expect potential performance gains > of at least 20:1. >=20 > Note that I'm not suggesting that either of these items is trivial. This is, unfortunately, quite true. Allowing non-atomic updates of the cg block means a lot of complications in the softupdate code, IMHO. --uAgJxtfIS94j9H4T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHFeBnC3+MBN1Mb4gRAtSOAKDuOFuqcDEHtsPa2r4oYii2aZeYgwCgoYZC fMAT7d/+eHzEZSeLe72yyzM= =zclz -----END PGP SIGNATURE----- --uAgJxtfIS94j9H4T--