Date: Wed, 17 Oct 2007 20:00:03 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Eric Anderson <anderson@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Filesystem snapshots dog slow Message-ID: <20071017100003.GK1191@turion.vk2pj.dyndns.org> In-Reply-To: <4714A663.5010800@freebsd.org> References: <20071016113046.GA35318@eos.sc1.parodius.com> <4714A663.5010800@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-16 06:54:11 -0500, Eric Anderson <anderson@freebsd.org> wrote: >will give you a good understanding of what the issue is. Essentially, your= =20 >disk is hammered making copies of all the cylinder groups, skipping those= =20 >that are 'busy', and coming back to them later. On a 200Gb disk, you could= =20 >have 1000 cylinder groups, each having to be locked, copied, unlocked, and= =20 >then checked again for any subsequent changes. The stalls you see are whe= n=20 >there are lock contentions, or disk IO issues. On a single disk (like you= r=20 >setup above), your snapshots will take forever since there is very little= =20 >random IO performance available to you. That said, there is a fair amount of scope available for improving both the creation and deletion performance. 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. 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. Between these two items, I would expect potential performance gains of at least 20:1. Note that I'm not suggesting that either of these items is trivial. --=20 Peter Jeremy --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFd0j/opHv/APuIcRAsDTAJ98bA1hM+azlznLoQYZ5NjV9XLClQCfTFSB afHPe9YjdIXOxI2m6LbrV3o= =NI2w -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017100003.GK1191>