--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+MBN1Mb4gRAtSOAKDuOFuqcDEHtsPa2r4oYi i2aZeYgwCgoYZC
fMAT7d/+eHzEZSeLe72yyzM=
=zclz
-----END PGP SIGNATURE-----

--uAgJxtfIS94j9H4T--