Status of SMB3?
smfrench at gmail.com
Mon Oct 20 11:35:01 MDT 2014
I should have mentioned that the mfsymlinks and apple style remap
changes are in 3.18-rc1 not in 3.17
On Mon, Oct 20, 2014 at 12:33 PM, Steve French <smfrench at gmail.com> wrote:
> This is a great question to explore now that significant SMB3
> improvements have gone into 3.17.
> SMB3 stability is much improved recently, in part due to the focus on
> automated xfstesting over the past
> months. In addition, it is much more posix compatible now.
> High level view:
> - SMB3 generally stable
> - SMB3 security is better than most alternatives (although finishing
> up krb5 support would help, and SMB3.1 looks like it will be better
> still when it is announced)
> - SMB3 (thanks to Pavel's improvements this summer) is faster for
> large file read/write than most alternatives.
> - SMB3 is getting better at full posix compliance/emulation but not as
> posix compliant as cifs dialect (with Unix extensions in the protocol)
> was to Samba, but about as compliant as cifs was to Windows.
> - SMB3 can now do emulated symlinks (mfsymlinks) similar to
> Apple (the "Minshall-French" style symlinks)
> - SMB3 now remaps the 7 reserved POSIX characters by default
> (similar to Windows "SFM" and Apple, no need to do "mapchars" unless
> you have legacy filenames created with this mount option which has :
> or ? or < > )
> - SMB3 can do emulated fifo and device files (with "sfu" mount option)
> - SMB3 can not retrieve posix mode bits from the ACL (yet) so would
> love help finishing this off, Shirish was looking at it too) ala the
> "cifsacl" mount option (which only works on cifs mounts)
> - SMB3 can not do extended attributes (yet)
> Known problems:
> xfstests has about 10 failures (not counting a few server bugs we
> found) shown when run with SMB3 mounts:
> - 3 due to the wrong return code returned on rename of directory tree
> onto an existing directory tree (was looking at adding an
> "smb3_rename_pending_delete" helper function as cifs has to see if
> that would help any of those)
> - 2 or 3 relating to minor fix needed to fallocate support (to clear
> local copy of pages on zero page fallocate)
> - 2 due to timestamp caching
> - 2 due to lack of posix mode emulation (posix permissions not
> available until cifsacl mount option finished)
> - better than alternatives for large file i/o
> - SMB2.1 and SMB3 leases are better than cifs oplocks which helps in
> some long running i/o cases due to the improved caching
> - chattier and slower than cifs for stat and readdir (SMB3 does
> open/query/close instead of cifs's querypathinfo - 3 operations
> instead of one). This could be improved with better operation
> compounding and some additional deferred close features.
> - The copy offload and even the set compression (chflags/chattr +C)
> can help - but the copy offload ioctl needs a little userspace copy
> util to call it (for fast server side copy offload when source and
> target are on the same server) as cifs.ko doesn't use the btrfs
> refcopy ioctl number for copy offload.
> - slower than cifs for most metadata heavy workloads - but could be
> improved to be much better than cifs (implementing SMB3 directory
> leases would be helpful)
> - finishing SMB3 multichannel (and RDMA) would be a big help for
> certain network constrained workloads
> - SMB3 packet signing should be pretty fast compared to alternatives
> SMB3 Unique Features
> Encrypted shares (would be useful to add and shouldn't be too hard)
> Durable handles (implemented), Persistent Handles (not implemented yet)
> Improved failover and Witness protocol would be very useful to add
> Overall - SMB3 could become the optimal file transfer mechanism for
> many more workloads with a few key improvements, but currently (3.17)
> is quite good for large i/o and reasonably stable, and more secure for
> some common use cases.
> On Mon, Oct 20, 2014 at 11:44 AM, Ben Greear <greearb at candelatech.com> wrote:
>> I notice at least some support for SMB3 in the 3.17 kernel.
>> Any idea how complete SMB3 support is?
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the samba-technical