Gary Mills wrote:
Should I file an RFE for this addition to ZFS? The concept would be to run ZFS on a file server, exporting storage to an application server where ZFS also runs on top of that storage. All storage management would take place on the file server, where the physical disks reside. The application server would still perform end-to-end error checking but would notify the file server when it detected an error.
Currently, this is done as a retry. But retries can suffer from cached badness.
There are several advantages to this configuration. One current recommendation is to export raw disks from the file server. Some storage devices, including I assume Sun's 7000 series, are unable to do this. Another is to build two RAID devices on the file server and to mirror them with ZFS on the application server. This is also sub-optimal as it doubles the space requirement and still does not take full advantage of ZFS error checking. Splitting the responsibilities works around these problems
I'm not convinced, but here is how you can change my mind. 1. Determine which faults you are trying to recover from. 2. Prioritize these faults based on their observability, impact, and rate. 3. For each fault, can it be solved using currently implemented means? Is there a way to improve recovery (likely)? The list that falls out of the bottom of this evaluation process should provide bounded, well-defined problems to solve. If the solution requires additions to protocols or even a new protocol, then that work would need to be started ASAP, because it can take years to implement. Currently, most protocols use retries as a basis. Few have anything more sophisticated. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
