better network filesystems

Steve French smfrench at austin.rr.com
Wed Dec 8 03:45:00 GMT 2004


OK - I buy that distinction of "server-less" for GFS or in the case of 
other cluster filesystems allowing more complex
topology (metadata servers, with various peers serving file data) while 
network filesystems have clearer and simpler
client vs. server roles.

The other two distinctions (between network and cluster filesystem) are 
true to a point, but are not really that
important:
1) "SAN Usage" can be done with extensions to network filesystems or 
cluster filsystems (as the NFS over RDMA
working group showed, or even the direct i/o experiments Microsoft talks 
about with CIFS).  IMO with Gigabit
and 10Gigabit coming down in price we are seeing the possibility that 
network filesystem performance could
be good enough "in the server room" even without SANs in some cases.

3) POSIX semantics - you can't really do perfect POSIX semantics anyway 
with Linux yet (e.g. there are a
few fcntl ops that are not hookable by any remote FS - neither cluster 
filesys nor network filesys - even the flock
API can not be hooked) so there is hard work (in the kernel, the vfs 
mapping layer itself) to do before
someone could do perfect posix file semantics.   We should of course try 
our best (and not settle for the
"we are broken the way NFS is" argument.  Believe it or not someone used 
the note in the man page for flock
(which notes that flock is broken over NFS see below) as an excuse not 
to fix flock in the VFS.
        "flock does not lock files over NFS"
We should do our best to make the semantics close to local - in some 
cases this means tradeoffs with perf
and thus options to  make POSIX semantics configurable would make sense. 
This is not really much
different than MS client - we should aim to allow Windows clients to 
Samba server the best  Windows
semantics possible for us to deliver.  If it were possible we would aim 
to pass --  ALL -- of the IFSTEST functional tests
remotely to Samba (at least pass all that NTFS can pass) unfortunately 
the Windowsclient IFS gets in the
way in a few cases.

In any case, I agree more or less with the distinctions - but certainly 
the second one is the strongest.

Christopher R. Hertel wrote:

>I'm on the GFS mailing list, so I asked about the distinction between a 
>cluster filesystem and a network filesystem.  Here's one response:
>
>On Tue, Dec 07, 2004 at 03:29:32PM +0800, David Teigland wrote:
>  
>
>>There seem to be at least three different things there that can be
>>considered separately:
>>
>>1. SAN usage
>>   CIFS/NFS aren't interested in exploiting SAN access from clients
>>   while others like GFS are.
>>
>>2. server role (symmetric vs asymmetric)
>>   GFS aims to be server-less, NFS/CIFS are very server-based, and
>>   others can fall somewhere in between.  (If you consider using GFS
>>   above iscsi or nbd then the differences become even more subtle.)
>>
>>3. POSIX semantics
>>   GFS semantics aim to copy those of a local fs exactly, while others
>>   like NFS don't, although there's nothing precluding that (NFS4 can
>>   be close if not exact).
>>    
>>
>
>I think it's the second point that's key.  Each node in the GFS cluster is 
>it's own client and server, interacting with the other nodes that also 
>have the device mounted.
>
>That third point echos something Steve said...
>
>Chris -)-----
>
>  
>




More information about the samba-technical mailing list