I know some others may already have pointed this out - but I can't see it and not say something...

Do you realise that losing a single disk in that pool could pretty much render the whole thing busted?

At least for me - the rate at which _I_ seem to lose disks, it would be worth considering something different ;)



On 12/19/11 09:05 AM, Jan-Aage Frydenbø-Bruvoll wrote:

On Sun, Dec 18, 2011 at 22:00, Fajar A. Nugraha<w...@fajar.net>  wrote:
 From http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
(or at least Google's cache of it, since it seems to be inaccessible

Keep pool space under 80% utilization to maintain pool performance.
Currently, pool performance can degrade when a pool is very full and
file systems are updated frequently, such as on a busy mail server.
Full pools might cause a performance penalty, but no other issues. If
the primary workload is immutable files (write once, never remove),
then you can keep a pool in the 95-96% utilization range. Keep in mind
that even with mostly static content in the 95-96% range, write, read,
and resilvering performance might suffer.

I'm guessing that your nearly-full disk, combined with your usage
performance, is the cause of slow down. Try freeing up some space
(e.g. make it about 75% full), just tot be sure.
I'm aware of the guidelines you refer to, and I have had slowdowns
before due to the pool being too full, but that was in the 9x% range
and the slowdown was in the order of a few percent.

At the moment I am slightly above the recommended limit, and the
performance is currently between 1/10000 and 1/2000 of what the other
pools achieve - i.e. a few hundred kB/s versus 2GB/s on the other
pools - surely allocation above 80% cannot carry such extreme

For the record - the read/write load on the pool is almost exclusively WORM.

Best regards
zfs-discuss mailing list

zfs-discuss mailing list

Reply via email to