[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: choice of network FSs

> > >>But that problem maybe solve via another solution. NFS is good for  
> > >>internal thin-clients, but even for server-server-filesharing I think  
> > >>there are better solutions (e.g. coda).  
> To overcome the current nfs limits I think NFSv4 availability in in current  
> kernels was already mentioned, and CIFS might also be an altenative.  
> But OTH there are some advantage in AFS:  
> https://lists.openafs.org/pipermail/openafs-info/2003-April/008931.html  
> To distribute between servers (performance) or laptops (disconected  
> operation) Intermezzo (http://inter-mezzo.org) is more light wheight than  
> Coda.  
In an interesting thread on a samba list Steven French posted[1] a nice  
>> SMB is icky, NetWare is even more closed, and NFS is okay, but somewhat  
>> outdated.  Coda has lots of problems, but one thing it has in its favor  
>> is disconnected operation.  
> Tim Potter wrote:  
>Have a look at nfs v4.  It's very nice both compared to SMB and previous  
>versions of nfs.  
Sounds like we are overdue for a high level comparison of network  
filesystems.   Here are some  
initial observations:  
     a) Huge installed client base (not just Windows),  
     b) good, open source server implementation available (Samba!),  
     c) token management (oplock) and referral ("dfs") semantics are a good  
        compromise between usefulness and simplicity  
     d) the key part of the filesystem protocol (mostly) documented,  
        rich file open semantics map well to Windows and related OSs,  
     e) kerberos security integration and RPC integration  
     f) broader in scope (print, ACL, browsing etc.) than other filesystem  
     g) optional PDU signing above the RPC allowing maximal flexibility  
     h) Unicode  
     i) high performance  
     j) huge amount of loosely related management/administrative function  
        available via various DCE RPC calls  
     k) efficient PDUs (small frame headers, less wasted bandwidth)  
     a) the extended protocol poorly documented,  
     b) not an IETF standard  
     c) elements of older protocol dialects still needed adding to  
        complexity of implementations  
     d) protocol needs addition of lock migration/recovery and support for  
        new transport mechanisms (e.g. RDMA)  
     e) ACL support - although useful is hard to understand  
     f) (item j above) management/admistrative calls are proprietary  
     a) relatively simple to implement  
     b) maps well to Unix VFS semantics (except for caching)  
     c) protocol easy to understand by stripping file protocol to its  
           [d) Unicode [this point was mistakenly writen]]  
     a) statelessness of core protocol causes caching problems  
     b) few Windows NFS clients installed  
     c) maps poorly to Windows operating system API  
     d) poor security (forcing it into lower layers if at all)  
     e) not a standard (informational description published by Sun as  
        informational RFC)  
     f) relatively weak open source server implementation (at least  
        compared to Samba and AFS) has scalability problems  
     g) implementing many protocols needed to get CIFS equivalent e.g. lock  
        manager, mount and port mapping protocol, SunRPC, NIS, ONC extensions  
        (some proprietary)  
     h) WebNFS enhancements partially implemented adding to some confusion  
     a) on track to be an IETF standard  
     b) improved recovery (lock migration)  
     c) supports Windows file sharing semantics better than NFS v3 did  
     d) safe file caching  
     a) few clients  
     b) perceived lack of Microsoft interest  
     c) the existing prototype open source implementation is tricky to  
        integrate into current Linux kernels  
     d) protocol is moving target (it is not quite done yet)  
     e) too late?  
     f) complex  
     a) Addition of RDMA to NFS style protocol, (probable) high performance  
        in clusters and server farms.  
     b) (see NFS v4)  
     a) unproven, lack of client support, perceived competition with NFS v4  
     b) (see NFS v4)  
     a) official standard  
     b) broadly implemented  
     c) well suited to internet  
     d) active standardization work - protocol will improve  
     a) frame headers are large (high % of frame size is wasted)  
     b) security integration not optimal  
     c) slow  
     d) not a complete match to either Linux VFS or Win2K IFS API  
     a) NDS integration  
     b) good match for Windows  
     c) good installed base on older systems  
     a) Proprietary  
     b) poorly documented  
     c) not a standard  
     d) complex, with lots of dialects  
     e) future clients questionable  
AFS/DFS: [now there is OpenAFS]  
   [ 0) real global namespace[2] ]  
     a) sophisticated distributed caching (token management)  
     b) DCE integration (including Kerberos and RPC)  
     c) standardized by OpenGroup  
     a) lack of clients  
     b) bulky, slow Windows clients  
     c) server integration with Unix operating systems and server  
        filesystem is complicated  
     d) most implementations were expensive  
     e) complex to implement  
     a) disconnected support  
     a) Lack of commercial implementations  
     b) lack of Windows clients  
     c) not well understood  
I'll add:  
     a) as a distributed FS syncer that is easier to understand  
     b) relies on well tested local filesystems  
     c) see coda (reimplementation from the same origin as Coda)  
     a) available in stock kernels only in stable 2.6   
       [I would not see lack of comercial implementations as a weakness,  
        but there is support http://www.clusterfs.com/intermezzo.html]  

Reply to: