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.
Sure -- the question at
You DO mean IPMP then. That's what I was trying to sort out, to make sure that
you were talking about the IP part of things, the iSCSI layer. And not the
paths from the target system to it's local storage.
You say non-ethernet for your network transport, what ARE you using?
This message
Oh sure pick nits. Yeah I should have said network multipath instead of
ethernet multipath but really how often do I encounter non-ethernet networks?
I can't recall the last time I saw a token ring or anything else.
This message posted from opensolaris.org
Vincent Fox wrote:
You DO mean IPMP then. That's what I was trying to sort out, to make sure
that you were talking about the IP part of things, the iSCSI layer. And not
the paths from the target system to it's local storage.
There is more than one way to skin this cat. Fortunately
| You DO mean IPMP then. That's what I was trying to sort out, to make
| sure th at you were talking about the IP part of things, the iSCSI
| layer.
My apologies for my lack of clarity. We are not looking at IPMP
multipathing; we are using MPxIO multipathing (mpathadm et al), which
operates at
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
In /kernel/drv/scsi_vhci.conf you could do this
load-balance=none;
That way mpxio would use only one device. I imagine you need a vid/pid
entry also in scsi_vhci.conf for your target.
Regards,
Vic
On Fri, Apr 4, 2008 at 3:36 PM, Chris Siebenmann [EMAIL PROTECTED] wrote:
We're currently
I assume you mean IPMP here, which refers to ethernet multipath.
There is also the other meaning of multipath referring to multiple paths to the
storage array typically enabled by stmsboot command.
We run active-passive (failover) IPMP as it keeps things simple for us and I
have run into some
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
| I assume you mean IPMP here, which refers to ethernet multipath.
|
| There is also the other meaning of multipath referring to multiple
| paths to the storage array typically enabled by stmsboot command.
We are currently looking at (and testing) the non-ethernet sort of
multipathing, partly as
10 matches
Mail list logo
