Shawn Joy wrote:
>If you don't give ZFS any redundancy, you risk loosing you pool if
there is data corruption.
It's a tradeoff. ZFS has more issues with loss of connectivity to the
underlying LUN than UFS, while UFS has issues with inability to detect
silent data corruption due to faulty HW writing/reading. I can't
quantify the actual occurrence of either to any specific number, so I
can't say the risk is more or less.
Is this the same risk for data corruption as UFS on hardware based luns?
If we present one LUN to ZFS and choose not to ZFS mirror or do a
raidz pool of that LUN is ZFS able to handle disk or raid controllers
failures on the hardware array?
No. But neither is /any/ other filesystem. At best, if you lose a
(non-redundant) hardware raid controller, you may be able to recover the
volume upon replacement of the raid controller. Maybe. It depends on
the failure mode of the raid controller. If the LUN itself is lost (i.e.
a single-disk LUN where the disk goes bad, or a HW-RAID volume where
failures exceed redundancy), no filesystem in the universe will help
you. I don't see any real difference between UFS and ZFS in these cases.
Does ZFS handle intermittent controller outages on the raid
controllers the same as what UFS would?
No. This is an issue with ZFS, as I noted in a previous post.
Intermittent outages on the SAN have a tendency to cause ZFS to mark the
LUN as "failed" - remember that ZFS acts both as a file system, and as a
software volume manager. Right now, I'm not aware of ways to make ZFS
more resilient to a "flakey" SAN infrastructure. Since UFS has no
awareness of a LUN's reliability (that would be in SVM), it will
happily try to use a device whose underlying LUN has gone away,
eventually reporting an inability to complete the relevant transaction
to the calling software.
Java System Support
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
zfs-discuss mailing list