Subject: [nfsv4] pNFS variants

From: [email-masked]
Date: Wed, 17 Nov 2004 11:46:50 -0500

Dave Noveck wrote:

> We already have three proposed variants of pNFS and, because of 
> hardware considerations, we may wind up having sub-variants (e.g. 
> iSCSI and FCP) but a proliferation of sub-variants such as we 
> would have if we tried to provide a standard definition of pNFS 
> over v3 or even pNFS over v2 (with a layout each subfile could 
> be kept under 4GB) is not a good thing.  More variants means 
> more work in implementation and testing and a lot less effective 
> interoperability as seen by the user.

I definitely agree with the desire to reduce variants.

In the block space, the need to for iSCSI vs. FCP variants
is not as clear as it might seem, because multi-pathing
(same volume [SCSI LU] exposed via distinct SCSI targets and
ports) makes it necessary to address the volume as opposed
to the SCSI target/port.  That addressing can be protocol-
independent (e.g., EMC has running pNFS-like code for NFSv3
and doesn't care about parallel SCSI vs. Fibre Channel).  If
there's a desire to use protocol-specific addressing (target
+ LUN), then per-protocol sub-variants will be needed, as
target addressing is protocol-specific, and there are a lot
of bad experiences in the block world with fragility of
target addressing (parallel SCSI is particularly bad, and
FC-AL can be as bad depending on how dynamic address assignment
is set up).  I would hope that for NFS layouts that v2 vs.
v3 vs. v4 differences can be eliminated or kept to a minimum.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4