On Sat, 2007-03-10 at 11:20 -0600, Mikkel L. Ellertson wrote: > Craig White wrote: > > On Sat, 2007-03-10 at 09:01 -0600, Mikkel L. Ellertson wrote: > >> Craig White wrote: > >>> I cannot envision a scenario where a cifs mount would work out better > >>> than an NFS mount for a Linux client but you are a bright guy and could > >>> possibly enlighten me. > >>> > >> Probably not. Your posts indicate you have already made up your > >> mine, so it would be a wasted effort. > > ---- > > I am a samba team member, if you think that I lack objectivity > > > > http://wiki.samba.org/index.php/SambaWiki:About > > > Then why are you giving mis-information? ---- I don't recall giving any mis-information, I asked for some clarity because I saw only one benefit (file locks) and many drawbacks for using cifs mounts vs nfs mounts for Linux clients. I asked for your perspective - seemed to be a pretty reasonable request. ---- > > > sure - a smbfs/cifs mount pretty much discards the concept of posix > > > users and doesn't understand Posix attributes, has no concept of the > > > case in file names and finally doesn't permit executables. > > Then you have in "man mount.cifs": > > uid=arg > sets the uid that will own all files on the mounted filesystem. > It may be specified as either a username or a numeric uid. This > parameter is ignored when the target server supports the CIFS > Unix extensions. > > file_mode=arg > If the server does not support the CIFS Unix extensions this > overrides the default file mode. > > I would think to most people that this would be show that cifs > understands Posix users and attributes as long as the server does. I > can find the documentation that says Samba does support the Unix > extensions, but I would think that you would already know this. ---- Unfortunately, I use RHEL and/or CentOS for servers which has a much older version of samba than Fedora (3.0.9-x for RHEL 3 and 3.0.10-x for RHEL 4) ---- > > There is also this in the cifs.txt file from the kernel documentation: > > The intent of this module is to provide the most advanced network > file system function for CIFS compliant servers, including better > POSIX compliance, secure per-user session establishment, high > performance safe distributed caching (oplock), optional packet > signing, large files, Unicode support and other internationalization > improvements. Since both Samba server and this filesystem client > support the CIFS Unix extensions, the combination can provide a > reasonable alternative to NFSv4 for fileserving in some Linux to > Linux environments, not just in Linux to Windows environments. ---- I don't have this file on my system but I believe that it must exist. I'm not sure that the suggestion that cifs 'can provide a reasonable alternative to NFSv4 for fileserving in some Linux to Linux environments' equates but I agree that the issue of what constitutes a reasonable alternative can be subjectively determined by those who use it. I think most important is the notion of using and promoting the native methodologies and protocols. The release of Microsoft Vista and it's undocumented changes firmly demonstrates that Windows networking security implementations and Windows networking protocols are in the control of Microsoft and while Samba does an excellent job of integration, promoting this as a methodology for Linux to Linux networking is the same thing as promoting '.DOC, .XLS, .PPS' data document storage formats. When you consider the confusion that is created for users with a file system mount that may or may not support durable UNIX attributes, I have to believe that NFS is a preferable methodology for Linux to Linux environments (file locking issues with simultaneous Windows usage ignored). Craig
