On Mon, Feb 2, 2009 at 9:22 PM, Gary Mills <mi...@cc.umanitoba.ca> wrote: > On Sun, Feb 01, 2009 at 11:44:14PM -0500, Jim Dunham wrote: >> If there are two (or more) instances of ZFS in the end-to-end data >> path, each instance is responsible for its own redundancy and error >> recovery. There is no in-band communication between one instance of >> ZFS and another instances of ZFS located elsewhere in the same end-to- >> end data path. > > I must have been unclear when I stated my question. The > configuration, with ZFS on both systems, redundancy only on the > file server, and end-to-end error detection and correction, does > not exist.
> What additions to ZFS are required to make this work? None. It's simply not possible. I believe Jim already state that, but let me give some additional comment that might be helpful. (1) zfs can provide end-to-end protection ONLY if you use it end-end. This means : - no other filesystem on top of it (e.g. do not use UFS on zvol or something similar) - no RAID/MIRROR under it (i.e. it must have access to the disk as JBOD) (2) When (1) is not fulfilled, you get limited protection. For example: - when using ufs on top of zvol, or exporting zvol as iscsi, zfs can only provide protection from zvol downwards. It can not manage protection for whatever runs on top of it. - when using zfs on top of HW/SW raid or iscsi, zfs can provide SOME protection, but if certain errors occur on the HW/SW raid or iscsi it MIGHT be unable to recover from it. Here's a scenario : (1) file server (or in this case iscsi server) exports a redundant zvol to app server (2) app server uses the iscsi LUN to create zpool (this would be a single-vdev pool) (3) app server has bad memory/mobo (4) after some writes, app server will show some files have checksum errors In this scenario, app server can NOT correct the error (it doesn't have enough redundancy), and file server can NOT detect the error (because the error is not under its control). Now consider a second scenario (1) file server exports several RAW DISK to app server (2) app server uses the iscsi LUNs to create zpool with redundancy (either mirror, raidz, or raidz2) (3) app server has bad memory/mobo (4) after some writes, app server will show some files have checksum errors In this scenario, app server SHOULD be able to detect and correct the errors properly, but it might be hard to find which one is at fault : app server, file server, or the disks. Third scenario (1) file server exports several RAW DISK to app server (2) app server uses the iscsi LUNs to create zpool with redundancy (either mirror, raidz, or raidz2) (3) file server has a bad disk (4) after some writes, app server will show some files have checksum errors, or it shows that a disk is bad In this scenario, app server SHOULD be able to detect and correct the errors properly, and it should be able to identify which iscsi LUN (and consequently, which disk on file server) is broken. Fourth scenario (1) file server exports several redundant zvols to app server (2) app server uses the iscsi LUNs to create zpool with redundancy (either mirror, raidz, or raidz2) (3) file server has a bad disk, or app server has memory errors In this scenario, app server or file server SHOULD be able to detect and correct the errors properly, so you get end-to-end protection. Sort of. Fourth scenario requires redundancy on both file and app server, while you mentioned that you only want redundancy on file server while running zfs on both file and app server. That's why I said it's not possible. Hope this helps. Regards, Fajar _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
