Ian Collins wrote:
I look after a remote server that has two iSCSI pools. The volumes for
each pool are sparse volumes and a while back the target's storage
became full, causing weird and wonderful corruption issues until they
manges to free some space.
Since then, one pool has been reasonably OK, but the other has terrible
performance receiving snapshots. Despite both iSCSI devices using the
same IP connection, iostat shows one with reasonable service times while
the other shows really high (up to 9 seconds) service times and 100%
busy. This kills performance for snapshots with many random file
removals and additions.
I'm currently zero filling the bad pool to recover space on the target
storage to see if that improves matters.
It did. Maybe the volume's free space had become very fragmented.
There are a couple of lessons here:
1) When using a thin provisioned volume for an iSCSI target, don't let
the volume's pool become full!
2) if the pool using the iSCSI target has a lot of churn, consider zero
filling the pool to flush out the free blocks.
--
Ian.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
