Joseph Barbey wrote:
Robert Milkowski wrote:
JB> So, normally, when the script runs, all snapshots finish in maybe
a minute
JB> total. However, on Sundays, it continues to take longer and
longer. On
JB> 2/25 it took 30 minutes, and this last Sunday, it took 2:11. The
only
JB> thing special thing about Sunday's snapshots is that they are the
first
JB> ones created since the full backup (using NetBackup) on Saturday. All
JB> other backups are incrementals.
hmmmmm do you have atime property set to off?
Maybe you spend most of the time in destroying snapshots due to much
larger delta coused by atime updates? You can possibly also gain some
performance by setting atime to off.
Yep, atime is set to off for all pools and filesystems. I looked
through the other possible properties, and nothing really looked like it
would really affect things.
One additional weird thing. My script hits each filesystem
(email-pool/A..Z) individually, so I can run zfs list -t snapshot and
find out how long each snapshot actually takes. Everything runs fine
until I get to around V or (normally) W. Then it can take a couple of
hours on the one FS. After that, the rest go quickly.
So, what operation exactly is taking "a couple of hours on the one FS"?
The only one I can imagine taking more than a minute would be 'zfs
destroy', but even that should be very rare on a snapshot. Is it always
the same FS that takes longer than the rest? Is the pool busy when you
do the slow operation?
You should be able to improve performance considerably (~26x) by using
just doing one 'zfs snapshot -r', 'zfs destroy -r', and 'zfs rename -r'.
(rename -r is in progress, should be available in OpenSolaris soon;
the others are in s10u3.)
--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
