[Federated-fs] FedFS Meeting Minutes, 9/11/2008
James Lentini
jlentini at netapp.com
Thu Sep 11 13:53:43 PDT 2008
FedFS Meeting Minutes, 9/11/2008
--------------------------------
Attendees
---------
Dan Ellard (BBN)
Craig Everhart (NetApp)
Robert Thurlow (Sun)
James Lentini (NetApp)
Dan Lovinger (Microsoft)
Theresa Raj (NetApp)
Minutes
-------
+ CIFS
To date, the fedfs protocols and architecture have been NFS specific. The
question has arisen if this infrastructure can accommodate CIFS.
Dan Lovinger who works on DFSN in the Windows Server & Tools group at
Microsoft joined us to answer questions on DFS, CIFS, and Windows. DFSN is
the set of protocols described in the MS-DFSNM and MS-DFSC documents.
- What is in a CIFS referral?
CIFS referrals have roughly the same functionality as NFSv4 referrals with
one interesting difference.
NFSv4 assumes that referrals are to other NFSv4 servers (there is no
support for other protocols).
DFSN allows the referral to contain a link to be any protocol. The Windows
client may interpret the link to be CIFS, WebDAV, NFS, or something else. A
CIFS referral contains a UNC pathname describing the target of the referral.
Out of the box, Vista comes with a CIFS and Webdav client. Other clients can
be installed.
Microsoft does not have an NFS client (v3,v4,..) at this time. Third party
NFS clients are available from companies such as Hummingbird.
- How does protocol switching work?
On the CIFS client, the list of referral targets is delivered up from the
CIFS client to the I/O subsystem. The I/O subsystem then evaluates the targets
regardless of what protocol the referral arrived on.
This behavior has been a part of Windows for around 8-10 years.
The client's system configuration controls how a path is interrupted. The
configuration prioritizes the list of protocols that will be used to interpret
the UNC paths.
As a result, two clients with different configurations could end up using two
different protocols to access the same path.
- How does the CIFS client detect a referral-capable share?
DFSN is an extra feature of an SMB share. There are two types of shares, ones
that are capable of generating a referral and ones that are not capable. The
ones that are not referral capable are similar to NFSv3 servers. They are
leaves in the namespace tree.
The protocol is backward compatible with older version of CIFS that do not support
referrals.
A DFSN-aware CIFS client asks for a referral as the first operation when
interacting with a share. This interrogation step is used to determine if the
state machine for handling referrals needs to be available. If the share
is unable to provide a referral, that state machine is de-activated for the
given mount and a subsequent referral will not work.
Therefore, all CIFS servers with FSNs that are internal nodes of the namespace
tree must be DFSN capable. At the very least, the server providing the
namespace root must be DFSN capable.
- How does this interact with FedFs?
Previously, we had assumed that an NFS client would always receive an referral to
an NFS server and a CIFS client would always receive a referral to a CIFS
server.
CIFS is more flexible than we had realized.
NFSv4 referrals are intended to be NFS only, although it is conceivable that
NFS could be extended to allow referrals to other protocols.
The task for FedFs is to keep the server informed of alternate paths. The
mechanism by which this information is communicated to the client is a separate
issue and the arena for discussing it is different. The consensus was that
the client referral mechanisms are outside the scope of FedFs and that FedFs
should concentrate on providing enough information to support the various
referral mechanisms.
We did not conclude if or how CIFS support would be added.
Does a multi-protocol namespace open up interesting new applications?
Could this answer the following quest: given the path of a CIFS share,
what is the corresponding NFS export path or vice versa?
One way to do this would be to walk the namespace from the root and map
each FSN path in the CIFS (NFS) namespace to the FSN path in the NFS (CIFS)
namespace. This would be rather expensive.
It would be easier if the namespaces mapped one to one, although we didn't
have time to discuss how that would be arranged.
+ Root Fileset
With Renu and Paul absent, we only spent about 10 minutes on this topic.
We came up with the following question for next week:
What are the requirements for the root fileset?
We also need to understand if this needs to be resolved completely before
the working group would consider taking on FedFs.
+ Next week
For next week:
- more on root fileset
- more on multi-protocol support
More information about the Federated-fs
mailing list