Ross wrote: > Well, you're not alone in wanting to use ZFS and iSCSI like that, and in fact > my change request suggested that this is exactly one of the things that could > be addressed: > > "The idea is really a two stage RFE, since just the first part would have > benefits. The key is to improve ZFS availability, without affecting it's > flexibility, bringing it on par with traditional raid controllers. > > A. Track response times, allowing for lop sided mirrors, and better failure > detection.
I've never seen a study which shows, categorically, that disk or network failures are preceded by significant latency changes. How do we get "better failure detection" from such measurements? > Many people have requested this since it would facilitate remote live > mirrors. > At a minimum, something like VxVM's preferred plex should be reasonably easy to implement. > B. Use response times to timeout devices, dropping them to an interim > failure mode while waiting for the official result from the driver. This > would prevent redundant pools hanging when waiting for a single device." > I don't see how this could work except for mirrored pools. Would that carry enough market to be worthwhile? -- richard > Unfortunately if your links tend to drop, you really need both parts. > However, if this does get added to ZFS, all you would then need is standard > monitoring on the ZFS pool. That would notify you when any device fails and > the pool goes to a degraded state, making it easy to spot when either the > remote mirrors or local storage are having problems. I'd have thought it > would make monitoring much simpler. > > And if this were possible, I would hope that you could configure iSCSI > devices to automatically reconnect and resilver too, so the system would be > self repairing once faults are corrected, but I haven't gone so far as to > test that yet. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
