Re: Filesystem snapshots dog slow

On 2007-Oct-16 06:54:11 -0500, Eric Anderson <anderson@xxxxxxxxxxx> wrote:
will give you a good understanding of what the issue is. Essentially, your
disk is hammered making copies of all the cylinder groups, skipping those
that are 'busy', and coming back to them later. On a 200Gb disk, you could
have 1000 cylinder groups, each having to be locked, copied, unlocked, and
then checked again for any subsequent changes. The stalls you see are when
there are lock contentions, or disk IO issues. On a single disk (like your
setup above), your snapshots will take forever since there is very little
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.

--
Peter Jeremy

Attachment: pgp2ObDpBGIo3.pgp
Description: PGP signature

Relevant Pages