> If you're clever, you'll also try to make sure each side of the mirror
> is on a different controller, and if you have enough controllers
> available, you'll also try to balance the controllers across stripes.
Something like this ?
# zpool status fibre0
pool: fibre0
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
fibre0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c2t16d0 ONLINE 0 0 0
c5t0d0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c5t1d0 ONLINE 0 0 0
c2t17d0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c5t2d0 ONLINE 0 0 0
c2t18d0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c2t20d0 ONLINE 0 0 0
c5t4d0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c2t21d0 ONLINE 0 0 0
c5t6d0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c2t19d0 ONLINE 0 0 0
c5t5d0 ONLINE 0 0 0
spares
c2t22d0 AVAIL
errors: No known data errors
However, unlike the bad old days of SVM ( DiskSuite or Solstice Disksuite
or Online Disk Suite etc ) I have no idea what algorithm is used to pick
the hot spare in the event of a failure. I mean, if I had more than one
hotspare there of course. Also, I think the weird order of controllers is
a user mistake on my part. Some of them have c5 listed first and others
have c2 listed first. I don't know if that matters at all however.
I can add mirrors on the fly but I can not ( yet ) remove them. I would
imagine that the algorithm to remove data from vdevs would be fairly
gnarly.
The item that I find somewhat confusing is how to apply multi-path fibre
devices to a stripe of mirrors. Consider these :
# mpathadm list lu
/dev/rdsk/c4t20000004CF9B63D0d0s2
Total Path Count: 2
Operational Path Count: 2
/dev/rdsk/c4t20000004CFA4D655d0s2
Total Path Count: 2
Operational Path Count: 2
/dev/rdsk/c4t20000004CFA4D2D9d0s2
Total Path Count: 2
Operational Path Count: 2
/dev/rdsk/c4t20000004CFBFD4BDd0s2
Total Path Count: 2
Operational Path Count: 2
/dev/rdsk/c4t20000004CFA4D3A1d0s2
Total Path Count: 2
Operational Path Count: 2
/dev/rdsk/c4t20000004CFA4D2C7d0s2
Total Path Count: 2
Operational Path Count: 2
/scsi_vhci/s...@g50800200001ad5d8
Total Path Count: 2
Operational Path Count: 2
Here we have each disk device sitting on two fibre loops :
# mpathadm show lu /dev/rdsk/c4t20000004CF9B63D0d0s2
Logical Unit: /dev/rdsk/c4t20000004CF9B63D0d0s2
mpath-support: libmpscsi_vhci.so
Vendor: SEAGATE
Product: ST373405FSUN72G
Revision: 0438
Name Type: unknown type
Name: 20000004cf9b63d0
Asymmetric: no
Current Load Balance: round-robin
Logical Unit Group ID: NA
Auto Failback: on
Auto Probing: NA
Paths:
Initiator Port Name: 21000003ba2cabc6
Target Port Name: 21000004cf9b63d0
Override Path: NA
Path State: OK
Disabled: no
Initiator Port Name: 210100e08b24f056
Target Port Name: 22000004cf9b63d0
Override Path: NA
Path State: OK
Disabled: no
Target Ports:
Name: 21000004cf9b63d0
Relative ID: 0
Name: 22000004cf9b63d0
Relative ID: 0
This is not disk redundency but rather fibre path redundency. When I drop
these guys into a ZPool it looks like this :
NAME STATE READ WRITE CKSUM
fp0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c4t20000004CFBFD4BDd0s0 ONLINE 0 0 0
c4t20000004CFA4D3A1d0s0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c4t20000004CFA4D2D9d0s0 ONLINE 0 0 0
c4t20000004CFA4D2C7d0s0 ONLINE 0 0 0
mirror ONLINE 0 0 0
c4t20000004CFA4D655d0s0 ONLINE 0 0 0
c4t20000004CF9B63D0d0s0 ONLINE 0 0 0
So the manner in which any given IO transaction gets to the zfs filesystem
just gets ever more complicated and convoluted and it makes me wonder if I
am tossing away performance to get higher levels of safety.
--
Dennis Clarke
dcla...@opensolaris.ca <- Email related to the open source Solaris
dcla...@blastwave.org <- Email related to open source for Solaris
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
