- 1 Introduction
- 2 Prerequisite / accompanying work
- 3 SMB 2.0
- 4 SMB 2.1
- 5 SMB 2.2
- 6 Cluster-Wide Durable Handles
This page describes the plan, design and work in progress of the efforts to implement SMB2 in Samba3.
- SMB 2.0 was introduces with Windows Vista/2008. Samba 3.6 added support for SMB2.0. This support is essentially complete except for one big item:
- durable file handles
- SMB 2.1 was introduced with Windows 7/Windows 2008R2. The major features to implement are:
- multi credit/large MTU
- resilient file handles
- branch cache
- unbuffered write
- SMB 2.2 will be introduced with Windows 8, which is currently (April 2012) available in a beta version. The features include:
- directory leases
- persistent file handles
- multi channel
- witness notification protocol (a new RPC service)
- interface discovery (a new FSCTL)
- SMB direct (SMB 2.2 over RDMA)
- remote shadow copy support
- branch cache v2
Prerequisite / accompanying work
VFS layering: introduce a NT-FSA-layer
Samba3's current VFS is a mixture of NT/SMB level calls (e.g. SMB_VFS_CREATE_FILE, SMB_VFS_GET_NT_ACL) and POSIX calls (e.g. SMB_VFS_OPEN, SMB_VFS_CHOWN). There are even lower level pluggable structures for specific POSIX ACL implementations. The implementations of the NT level VFS calls also call out into the POSIX level calls. The idea of this part is to split up the layers, so that the layering is clean: A NT-Layer on top that implements only the NT/SMB style calls. This should be guided by the FSA description from the Microsoft documentation ([MS-FSA]). Some of the NT/SMB-level calls are not present in the current SMB_VFS yet at all so these would have to be abstracted out of the smbd code. The current implementation of the SMB_VFS calls and some portion of smbd code would become the default "POSIX" backend to the FSA vfs layer.
This step is technically not strictly necessary, but a desired foundation for the SMB2 and future changes. When we touch the code anyways, we have a chance to improve the structure and untangle the layers. We don't need to do it in one step and we don't need to implement all of FSA right away, but we can tryp to improve the layering as we go along and touch calls.
- does not depend on other work
- accompanies work on the whole project
- The splitting out of NTFSA calls can be made a prerequisite for further work on the corresponding calls in work on SMB 2.0 durable handles and SMB 2.1 (e.g. leases and resilient file handles).
- define VFS structures:
- NTFSA layer
- POSIX backend to call into the current SMB_VFS
- first implement NTFSA by calling directly into current SMB_VFS code (or move code from smbd into the default NTFSA backend implementation) and have smbd call out into the FSA layer instead
- start with one call after another, e.g. smb2_create and use NTFSA calls in the implementation.
- Move logic from the smbd/ code to new NTFSA calls. These call the lower layer SMB_VFS calls.
- Once the NTFSA calls are used everywhere, one can start to split up and fix the vfs layering underneath, i.e. remove the FSA-style calls from the SMB_VFS etc.
- data structures: split up files / connections into smbXsrv layer and fsa layer, e.g.:
smb level | ntfsa | ntfsa_posix level smbXsrv_session --> ntfsa_context --> users_struct smbXsrv_tcon --> ntfsa_context --> connections_struct smbXsrv_open --> ntfsa_open --> files_struct