On Wed, 4 Mar 2009, Stephen Nelson-Smith wrote:
The interesting alternative is to set up Comstar on SXCE, create zpools and volumes, and make these available either over a fibre infrastructure, or iSCSI. I'm quite excited by this as a solution, but I'm not sure if it's really production ready.
While this is indeed exciting, the solutions you have proposed vary considerably in the type of functionality they offer. Comstar and iSCSI provide access to a storage "volume" similar to SAN storage. This volume is then formatted with some alien filesystem which is unlikely to support the robust features of ZFS. Even though the storage volume is implemented in robust ZFS, the client still has the ability to scramble its own filesystem. ZFS snapshots can help defend against that by allowing to rewind the entire content of the storage "volume" to a former point in time.
With the NFS/CIFS server model, only ZFS is used. There is no dependence on a client filesystem.
With the Comstar/iSCSI approach, you are balkanizing (http://en.wikipedia.org/wiki/Balkanization) your storage so that each client owns its own filesystems without ability to share the data unless the client does it. With the native ZFS server approach, all clients share the pool storage and can share files on the server if the server allows it. A drawback of the native ZFS server approach is that the server needs to know about the users on the clients in order to support access control.
Regardless, there are cases where Comstar/iSCSI makes the most sense, or the ZFS fileserver makes the most sense.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
