| |||||||||||||
|
| |||||||||||||
CIFS? Really?CIFS? Really?Posted Feb 9, 2007 2:51 UTC (Fri) by proski (subscriber, #104)In reply to: CIFS? Really? by madscientist Parent article: Why a secret patent deal won't help Linux/Windows (LinuxWorld) I don't think Samba was ever about replacing NFS. It is about replacing Windows file and servers while keeping the protocol and the clients. Replacing NFS with something better designed is a completely separate effort.
(Log in to post comments)
CIFS? Really? Posted Feb 9, 2007 10:10 UTC (Fri) by lamikr (guest, #2289) [Link] Do you know some projects dealing with the NFS replacement?
CIFS? Really? Posted Feb 9, 2007 14:00 UTC (Fri) by mbottrell (guest, #43008) [Link] Like CODA, OpenAFS, InterMezzo or Lustre to start with?
CIFS? Really? Posted Feb 9, 2007 20:29 UTC (Fri) by khim (subscriber, #9252) [Link] How fast can you copy 25GB file from one xxxfs server to another one ? With NFS or CIFS the answer is "pretty darn fast". All filesystems you've mentioned such at this. They have a lot of other interesting qualities, but they are not NFS replacement, sadly...
CIFS? Really? Posted Feb 9, 2007 23:14 UTC (Fri) by drag (subscriber, #31333) [Link] Yep. Plus Coda and Intermezzo are dead dead dead.
OpenAFS I've used before. It's very nice for networks were you have large amounts of distributed users over insecure and unreliable networks.
Say if I wanted to do file sharing over a widespread campus with heavy use of wireless then OpenAFS would entirely kick-rear. It has heavy local cache and has acceptable levels of authentication (kerberos 4) and crypto (not aas strong as ssh, but better then CIFS).
A person can be using OpenAFS, editing files on it and such, loose the connection to the server (temporarially) and still be able to work with their files. Also you can move and mirror volumes from server to server and it is completely transparent to the end users becuase it uses a world-wide directory system were you have mount points and such, similar to Unix directory system.. rather then "server:/share" model for NFS or other common network fs's.
However it has severe limitations. It won't handle large files well at all. Completely unsuitable. It's for small text files. Volumes are non-native to Linux.. you need to have OpenAFS running to access the files on the server which can complicate recovery. File permissions are not POSIX. Volume sizes are severly limited.
User training is hard. Since it's not posix file permissions are very confusing and overall it's confusing to people used to using computers.
The upshot is that since it's been open source'd it's stability and usefullness has increased dramaticly and it has a healthy development community.
Lustre is very very interesting. Lustre folks have contributed a lot of improvements to Ext3 and will have a lot of involvement in Ext4, I beleive. Its a POSIX fs, it supports Linux-style ACLs, and most of the important bits that it uses are already in the kernel and being used in other FS's.
Performance is very very high. It's been used to break speed records.
It's very distributed and has lots of failover features. Seperate Metadata servers, volume servers, distributed lock server, etc. Performance and scalability can be very good as your files aand volumes will be distributed across many machines. You can agregate bandwidth and other stuff.
It can tie into SANs, or be used off of PC hardware. Supports all the hip stuff like remote DMA, exploit gigabit ethernet/fiberchannel/infinaband fully.
It's efficient, claiming in benchmarks to get 944Mb/s file transfer performance on a gigabit network.
blah blah blah.
Pretty much any sort of file system feature you could ever want in a distributed clustering file system in the enterprise is aviable in Lustre.
Then you have the ability to export volumes so that they can be accessed via NFS or CIFS.
The major downside right now is that it's going to be hugely complicated to deploy. Also there is no strong security for it right now, due it being targetted for high performance computing applications before being general-use (which it's aiming for). Hopefully by the end of this year they will get initial support for Kerberos and other strong security models.
CIFS? Really? Posted Feb 15, 2007 6:00 UTC (Thu) by k8to (subscriber, #15413) [Link] Some random comments.
Coda may be dead, but it claims that it is not. Some of the researchers inside CMU are trying to get it a bit more produciton ready and float it into the wider community. I too thought it was dead until recently, and it may only be on life-support, but they're trying.
AFS, Coda, and even Lustre all fail for the case of a small network. Say a family-sized network. They all require dedicated storage volumes which means planning ahead and some kind of information management person. The case of "I want to make this directory available read-only to my mom and sister" seems to be handled poorly by every protocol. NFS has no reasonable user selection, CIFS has a baroque windows-oriented user selection. They all have poor error messages and involve lots of reading log files to get things working.
It really would be nice to have a relatively easy to set up network filesystem that could work with sane semantics in a heterogeneous way. I guess this is a hard problem though since semantics on some platforms are insane. Huge bonus points for pleasant behavior in disconnect state.
CIFS? Really? Posted Feb 9, 2007 10:10 UTC (Fri) by drag (subscriber, #31333) [Link] Well from other interviews I've heard from Samba developers they have very very good reasons why NFS sucks and why NFSv4 sucks and such (which I suppose people here can understand their points better then I)
The deal is that SMB/CIFS stuff is one of those it's a standard, but it's not a standard. It's one of those things that so much is left up in the air in terms of the actual protocol design you can make it pretty much do whatever you want.
So the idea to make Samba better native network FS for Linux workgroups then NFS is to modify Samba to automaticly detect weither or not both hosts are Linux (or probably include BSDs and such) and then when that happens they have the client and server just completely bypass all the Windows compatability crud and use optimized protocols specificly for Linux.
Do things like support Linux-style ACLs properly, support special file types properly, and make it so that you can do things like setup your /home on a Samba share or boot off of a Samba share with no compatability issues.
So the idea is that this would be integrated into Samba and one the many many different variations on 'SMB' that it supports.
(Pretty much for every version of Windows released, Microsoft changed the protocol. SMB acts differently on a mobile device vs desktop. Windows XP/2003 is incompatable with Windows file sharing when done without Active Directory support, DOS versions have their own SMB protocol that Samba supports, etc etc etc.)
For my personal life the FUSE version of sshfs has effectively replaced Samba and NFS. It's much faster then Samba, and it's even faster then NFS for networks that are 100MB/s and slower. Also with the various authentication protocols that SSH supports then it's very easy to setup and make secure and convient to use. But I wouldn't want to use it in a heavily multiuser environment and you can't do things like boot off of it and such.
It would be nice to have a replacement protocol that would work with Fuse. FunFS was interesting and it was suppose to be _much_ faster then NFS, but it's dead now.
But Samba is pretty good and everybody has to use it anyways for Windows compatability, so why not make it faster and more compatable with Linux?
CIFS? Really? Posted Feb 9, 2007 10:14 UTC (Fri) by drag (subscriber, #31333) [Link] Oops ment 100Mb/s and slower, not 100MB! NFS has a good edge over sshfs on gigabit networks, even without any tuning.
Although OpenISCSI initiator with 'Enterprise iSCSI Target' is faster (but obviously not suitable for environments were you have many clients.)
CIFS? Really? Posted Feb 15, 2007 6:08 UTC (Thu) by k8to (subscriber, #15413) [Link] sshfs when you manually request blowfish works okay, but at a pretty high cpu cost. It frsutrates me for lan usage that the OpenSSH people refuse to support the 'none' cipher, because sshfs would be much more competitive.
However sshfs is VASTLY inferior in the realm of cacheing to both CIFS and NFS. A repeated ls with a minute of pause can incur significant lag with sshfs, wheras nfs or cifs will leave it instantaneous. Also while NFS and CIFS may be very unpleasant in handling the restoration of client/server connectivity, sshfs simply fails entirely.
sshfs also does not support the full range of file semantics without error. Try mmapping in a few large files from sshfs, and your program will likely encounter mysterious stalls which do not recover.
That said, for many use cases sshfs is by far the best choice. It has far more sane permission handling, and the lack of need to specially configure the server is fantastic. Error reporting is clear and accessible, and peformance is quite livable for very small files, low access, and low bandwidth.
|
|
||||||||||||