>>>>> "nw" == Nicolas Williams <[EMAIL PROTECTED]> writes:
nw> But does it work well enough? It may be faster than NFS if You're talking about different things. Gray is using NFS period between the storage cluster and the compute cluster, no iSCSI. Gray's (``does it work well enough''): iSCSI within storage cluster NFS to storage consumers Marion's (less ``uncomfortable''): nothing(?) within storage cluster pNFS to storage consumers but Marion's is not really possible at all, and won't be for a while with other groups' choice of storage-consumer platform, so it'd have to be GlusterFS or some other goofy fringe FUSEy thing or not-very-general crude in-house hack. I guess since Gray is copying data in and out all the time he doesn't have to worry about the glacial-restore problem and corruption problem. If it were my worry, I'd definitely include NFS clients in the performance test because iSCSI is high-latency, and the NFS clients could be more latency-sensitive than the local benchmark. I might test coalescing in the big data separately from running the crunching, because maybe the big data can be copied in with pax-over-netcat, or something other than NFS, and maybe the crunching could treat the big data as read-only and write its small result to a fast standalone ZFS server which would make NFS faster. and i'd get the small important data that needs backup off this mess (but please let us know how the failure simulating testing goes!).
pgpM2yKwKqo4d.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss