>In life there are many things that we "should do" (but often don't). >There are always trade-offs. If you need your pool to be able to >operate with a device missing, then the pool needs to have sufficient >redundancy to keep working. If you want your pool to survive if a >disk gets crushed by a wayward fork lift, then you need to have >redundant storage so that the data continues to be available. > >If the devices are on a SAN and you want to be able to continue >operating while there is a SAN failure, then you need to have >redundant SAN switches, redundant paths, and redundant storage >devices, preferably in a different chassis.
Yes, of course. This is part of normal SAN design. The ZFS file systems is what is different here. If a either a HBA, fibre cable, redundant controller fail or firmware issues on a array redundant controller occur then SSTM (MPXIO) will see the issue and try and fail things over to the other controller. Of course this reaction at the SSTM level takes time. UFS simply allows this to happen. It is my understanding ZFS can have issues with this hence the reason why a zfs mirror or raidz device is required. Still not clear how the above mentioned BUGS change the behavior of zfs and if they change the recommendations of the zpool man page. > >Bob >-- >Bob Friesenhahn >bfriesen at simple dot dallas dot tx dot us, >http://www.simplesystems.org/users/bfriesen/ >GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
