>>>>> "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
