better network filesystems

[Michael B Allen]

On Mon, 06 Dec 2004 23:06:59 -0600
Steve French <smfrench at austin.rr.com> wrote:
> >CIFS is too many layers of protocol. Think about the
> >layers one goes through to write a buffer of data in an RPC -- NetBIOS ->
> >SMB -> SMB Transactions -> Named Pipe -> DCE PDU. NFS doesn't integrate
> >with The Enterprise easily. Think about what is involved in setting up a
> >server, creating an export and granting access to the right users.
> >  
> >
> I disagree with that though - CIFS is as simple as I think you can 
> reasonably get for the key read/write operations.
> You have a length field and about a 33 byte SMB header and can 
> read/write up to 128K

Ok, but you have to do transactions to stat a file and when you get to
find_first/next things start to get ugly.

> with -- no RPC -- no XDR

Agreed. As a RAD tool or for commodity development RPCs makes sense but I
never understood why they were used for high performance protocols that
don't change that much over time. Yeah, it takes longer initially but the
code will be simpler and you could probably still autogenerate a good part
of the marshalling routines.

> probably less overhead.   SPNEGO is complicated
> as are the Kerberos exchanges but it is hard to blame CIFS for that 
> (everyone else is stuck with those IETF standards too and
> they are fairly well proven).

Actually I've been reading the Kerberos5 RFC was pleasantly surprised. I
went into it thinking it was this really complicated beast. Yeah, the crypto
is beyond me but I understand the high level stuff and it's very elegant.
RFC 1510 is also pretty well written (unlike GSS-API which is a long-winded
way of describing read()/write().

> To bring in DCE/RPC is not really fair 
> as the ops that flow over DCE/RPC over CIFS generally
> have no equivalent in NFS anyway and DCE/RPC is not needed/used in 
> mapping kernel VFS ops to the Samba server
> (maybe someday in  mount you -- might -- use a few RPCs).

A complete solution needs management functions for creating exports,
changing ACLs, mount options, security modes, etc.

> I agree that 
> DCE/RPC is hard for "managing" servers but have

Actually the basic DCE/RPC mechanism would be fine if it was just used over
TCP/IP transport (and provided programmers didn't leave exploits all over
the place).

> I prefer just taking what
> we know and trivially extending and fixing it [cifs] (for optimal behavior
> with open clients - so they can get excellent semantics
> and performance) as jra, tridge et al are doing now while maintaining 
> the compat with the Windows half as best we reasonably can.

Well obviously we're going to be using CIFS for a while still so I don't see
any harm in working off it. Trying to push something new is just such a long
hard road. But if I was in charge and had to make a command decision about
sticking with CIFS or reimplementing something from scratch to replace it I
would definately choose to reimplement. I wouldn't even listen to arguments.

> It is easy to make design mistakes (which we realize as we poke holes at 
> SMB/CIFS and NFS) but I worry with all of the
> discussion about new cluster filesystems that new unrelated protocols 
> don't necessarily fix old mistakes (made by the protocols
> we have learned to love and hate) as they reinvent the wheel  ...  :)

I wouldn't worry too much. A new system would have to be truely good to
supplant CIFS. Even MS would have a really tough time just declaring that
there's some new thing. It would have to have all the features, be
open/patent free, simple, and modular so it could grow. I think it would
actually be a pretty straight forward project conceptually. It's just very
unlikely that someone would have the time and resources to do it right. It
would need a handful of really experienced people and heavy shielding from
bureaucracy and politics. Ha. No.

Mike

-- 
Greedo shoots first? Not in my Star Wars.