On Fri, 26 Feb 2010, Shane Cox wrote:
I've reviewed the forum archives and read a number of threads related to this
issue. However I
didn't find a root-cause explanation for these pauses, only talk of how to
ameliorate them. In my
particular case, I would like to know why zfs_log_writes are blocked for 180ms
on a mutex (seemingly
blocked on the intent log itself) when performing zil_itx_assign. Another
thread must have a lock on
the intent log, no? Overall, the system appears healthy as other system calls
(e.g., reads and
writes to network devices) complete successfully while writes to the intent log
are blocked ... so
the problem seems to be access to the zfs intent log.
Any additional insight would be appreciated.
As far as I am aware, none of the zfs authors has been willing to
address this issue in public. It is not clear (to me) if the
fundmental design of zfs transaction groups requires that writes stop
briefly until the transaction group has been flushed to disk. I
suspect that this is the case.
Perhaps zfs will never meet your timing requirements. Others here
have had considerable success by using RAID interface adaptor cards
with battery-backed cache memory and configuring those cards to "IT"
JBOD mode. By limiting the TXG group size to the amount which will
fit in battery-backed cache memory, the time to "commit" the TXG group
is dramatically reduced as long as the continual write rate does not
exceed what the backing disks can sustain. Unfortunately, this
may increase the total amount of data written to underlying storage.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
