On Thu, Jun 22, 2006 at 04:22:22PM -0700, Joe Little wrote:
> Again, the issue is the multiple fsyncs that NFS requires, and likely
> the serialization of those iscsi requests. Apparently, there is a
> basic latency in iscsi that one could improve upon with FC, but we are
> definitely in the all ethernet/iscsi camp for multi-building storage
> pool growth and don't have interest in a FC-based SAN.
There may be two things going on here. One is the fsync()s. So many
fsync()s, required by the semantics of NFS serialize I/O too much
(which, with a client doing single-threaded things, kills), and, looking
at Roch's Dynamics of ZFS blog entry, perhaps there's some aliasing of
fsync() pressure as memory pressure/disk I/O saturation. From Roch's
blog entry:
CAVEAT: The current state of the ZIL is such that if there is a lot
of pending data in a Filesystem (written to the FS, not yet output
to disk) and a process issues an fsync() for one of it's files, then
all pending operations will have to be sent to disk before the
synchronous command can complete. This can lead to unexpected
performance characteristics. Code is under review.
Since NFS is doing so many fsyncs this, I reason, can force many writes
into txg+2, thus triggering throttling of the NFS server threads.
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
