From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steven French" Subject: Re: CIFS VFS Date: Tue, 1 Oct 2002 12:30:28 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: To: Christoph Hellwig List-Id: linux-fsdevel.vger.kernel.org Sure. This had been discussed among the Samba community starting at last year's CIFS conference and again at the plugfests and interoperability events this year. I do not view the CIFS VFS as necessarily replacing smbfs, since smbfs provides interoperability with older servers (prior to NT 4) which is still of value to some users. There were basically three reasons that we did not start from smbfs and felt that an additional filesystem was necessary to support the newer version of the protocol. 1) Limited reuse potential - smbfs was missing quite a bit of the newer function needed which after looking at for a while and seemed easier to implement from scratch rather than try to force fit into smbfs, and customers could then choose whether they wanted to use the newer more experimental CIFS vfs or the older smbfs. 2) The recommendation of one of the previous smbfs maintainers (and some of the Samba team) last year who put a complete rewrite of smbfs fairly high on the list of the "samba-related" items that needed to get done. Comments included perceived design problems in the original design of smbfs, lack of structure definitions for most key protocol elements and no support for a few key Samba features. 3) smbfs seemed to have different design goals including broad compatability with old servers (much like nfs v2 provides broad compatability vs. nfs v4 which provides useful new function) while we wanted to take advantage of features only available in current servers and also to provide a more useful reference implementation for the client end of new extensions to CIFS such as the CIFS Unix Extensions (Samba already provides this for the server side) as our work in the CIFS Technical Workgroup in the Storage Networking Industry Association continues. In addition there were other design differences that were fairly fundamental - an important chunk of smbfs is implemented in user space, which makes implementing ms dfs (heirarchical name space) difficult and would make it impossible to boot (diskless systems) from and also complicates reconnection. Finally another big difference in design goals is that smbfs preferentially uses Netbios naming and port 139 (as it should as an smb filesystem) while the CIFS VFS preferentially uses TCP naming and port 445 (as CIFS systems are supposed to) although it can fall back to 139. The design goals that we started with were the following. Most of these were not implemented in smbfs when we started, although a few have been added to the kernel as patches (e.g. on Urban's web site) and others. Features we have implemented in the CIFS VFS so far: 1) "Pure TCP/IP" (port 445 in addition to RFC1001 port 139) support (NB the mount.cifs mount helper, needed for calling gethostbyname, is not quite complete) 2) Full POSIX support including use of CIFS Unix Extensions and NT hardlinks etc. 3) Support for "raw NTLMSSP" (security negotiation) and more secure session establishment 4) Large file handling (larger than 2GB up to 2**63 in size) 5) Internationalization improvements (Unicode on the wire) 6) Use of SetPathinfo instead of SetFileInfo where appropriate, use of current levels for CIFS transact2 calls 7) Use of 32 bit errors (cifs network status codes) vs old dos error codes. 8) Byte Range and File locks 9) Improved support for Symbolic links (NB Samba bug blocks some POSIX test cases for some types of symlink names) 10) Improved debugging, procfs support 11) Case sensitive searches (done) and Unix behavioral defaults Features that are being worked (in progress): 1) Transparent reconnection after tcp or cifs session failure 2) Globally rooted, AFS-like heirarchical name space 3) Kerberos/SPNego authentication 4) NTLMv2 encryption 5) Distributed Lock/Token Management (e.g. Level I and II oplocks) - safe client data caching 6) optional Multiple security contexts and transparent local to network UUID mapping 7) Performance improvements (e.g. command chaining, overlapping multiplexed PDUs to same server, reduced copy overhead, gather send using multiple iovecs, optimized dialect usage) And features that we will be starting on next: 1) Per SMB security signatures (needed in many cases for .Net server compat) 2) Replicated volumes 3) Mounts to multi-component UNC names (mounts to 4) Improved PAM/NSSwitch module integration (if a network authentication module such as Winbind or PAM_Kerberos or PAM_LDAP are configured, for example) 5) Network alias support (not started) 6) Directory and File change notification for optional safe caching of inode metadata (not started) 7) Support for CIFS ACLs and xattr support (not started) 8) Improved Support for Disk Quotas (not started) 9) CIFS Sparse files and some related network IOCTLs (not started) 10) Offline files and CIFS heirarchical storage support The CIFS VFS has been going through lots of interoperability testing, starting at Connectathon and including this years CIFS Conference and plugfest (smbfs was not tested at these). IBM developed the initial smb filesystem years ago and it is still the "native" remote filesystem for OS/400 (and of course IBM PC-DOS and OS/2) so it also seemed appropriate that we should help out Linux interoperability in this area especially given the explosion of storage appliances that implement CIFS and also the large number of Windows and Samba servers. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench@us.ibm.com