On Tue, 13 Oct 2009, Shawn Joy wrote:
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.
ZFS does not seem so different than UFS when it comes to a SAN. ZFS depends on the underlying device drivers to detect and report problems. UFS does the same. MPXIO's response will also depend on the underlying device drivers.
My own reliability concerns regarding a "SAN" are due to the big-LUN that SAN hardware usually emulates and not due to communications in the "SAN". A big-LUN is comprised of multiple disk drives. If the SAN storage array has an error, then it is possible that the data on one of these disk drives will be incorrect, and it will be hidden somewhere in that big LUN. The data could be old data rather than just being "corrupted". Without redundancy ZFS will detect this corruption but will be unable to repair it. The difference from UFS is that UFS might not even notice the corruption, or fsck will just paper it over. UFS filesystems are usually much smaller than ZFS pools.
There are performance concerns when using a big-LUN because ZFS won't be able to intelligently schedule I/O for multiple drives, so performance is reduced.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
