[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