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