ZFS will handle out of order writes due to it transactional nature. Individual writes can be re-ordered safely. When the transaction commits it will wait for all writes and flush them; then write a new uberblock with the new transaction group number and flush that.
Chris Siebenmann wrote: > We're currently designing a ZFS fileserver environment with iSCSI based > storage (for failover, cost, ease of expansion, and so on). As part of > this we would like to use multipathing for extra reliability, and I am > not sure how we want to configure it. > > Our iSCSI backend only supports multiple sessions per target, not > multiple connections per session (and my understanding is that the > Solaris initiator doesn't currently support multiple connections > anyways). However, we have been cautioned that there is nothing in > the backend that imposes a global ordering for commands between the > sessions, and so disk IO might get reordered if Solaris's multipath load > balancing submits part of it to one session and part to another. > > So: does anyone know if Solaris's multipath and iSCSI systems already > take care of this, or if ZFS already is paranoid enough to deal > with this, or if we should configure Solaris multipathing to not > load-balance? > > (A load-balanced multipath configuration is simpler for us to > administer, at least until I figure out how to tell Solaris multipathing > which is the preferrred network for any given iSCSI target so we can > balance the overall network load by hand.) > > Thanks in advance. > > - cks > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
