Thank You all for the comments. You should imagine a datacenter with - standards not completely depending on me. - SAN for many OSs, one of them is Solaris, (and not the major amount) - usually level 2 engineers doing filesystem increases. - hundreds of physical boxes, dozens of virtuals on one physical - ability to move VMs (zones) across physical boxes. (by assigning LUNs to other boxes)
That probably explains, that I cannot use host based raid management, it is done by storage as standard. I cannot assign whole disks to boxes, as I get LUNs standardized for all other OSs, and in a size optimized for virtual small virtual machines. zfs is just used for easy expansion, and snapshotting. >If your SAN group gives you a LUN that is at the opposite end of the array, I >would think that was because they had >already assigned the space in the >middle to other customers (other groups like yours, or other hosts of yours.) >Adding your second LUN to the mix isn't going to seriously change the workload >on the disks in the array. Though I agree, that I cannot guarantee what other hosts are doing on my LUNs, I still think that I would avoid striping over partitions on the same disk. The possible bad thing is better than an absolutely sure bad thing. On 10/18/2010 5:40 AM, Habony, Zsolt wrote: >> (I do not mirror, as the storage gives redundancy behind LUNs.) >> >By not enabling redundancy (Mirror or RAIDZ[123]) at the ZFS level, >you are opening yourself to corruption problems that the underlying >SAN storage can't protect you from. the SAN array won't even notice >the problem. So, I cannot redefine our standards here. Maybe zfs does some things better than the storage, but having standards for all the other OSs also gives advantages, and yes I know we sacrifice some useful zfs features. I hope that explains, and thank you again for all your valuable comments. Zsolt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
