ntvfs vs s3fs

[Michael Adam]

Andrew Bartlett wrote:
> On Tue, 2012-07-03 at 11:07 +0100, Mike Howard wrote:
> > On 03/07/2012 08:12, Matthieu Patou wrote:
> > > Hi Mike,
> > >>> Samba 4.0 also ships with the 'NTVFS' file server.  This file server
> > >>> is what was used in all previous alpha releases of Samba 4.0, and is
> > >>> tuned to match the requirements of an AD domain controller. We
> > >>> continue to support this, not only to provide continuity to
> > >>> installations that have deployed it as part of an AD DC, but also as a
> > >>> running example of the NT-FSA architecture we expect to move smbd to in
> > >>> the longer term.
> > >>>
> > >>>
> > >>
> > >> So if one is not intending to act as a files erver, purely an 
> > >> authenticating dc (please excuse terminology), would you advise 
> > >> running samba4 with the NTVFS file server?
> > > Well if you don't use the Fileserver thing of the AD then why bother 
> > > about which fileserver is used ?
> > >
> > > Matthieu.
> > 
> > I guess it was the comments in the release statement that made me ask 
> > the question, specifically these two comments;
> > 
> > "This file server is what was used in all previous alpha releases of 
> > Samba 4.0, and is tuned to match the requirements of an AD domain 
> > controller."
> > 
> > "As mentioned above, this change to the default file server may cause 
> > instability, as we learn about the real-world interactions between these 
> > two key components.
> > 
> > The word 'tuned' in the first one and 'instability' in the second 
> > attracting my attention. I suppose it's likely that even if data isn't 
> > served by the dc, profiles may well be (in my scenario).
> 
> The warning is there for a reason - we have had issues with the new
> s3fs, but we need to find them, not just ignore them, as the agreement
> of the team is that this will be the default file server for the 4.0
> release.
> 
> For example, we only just found and solved the issue where a blocking
> fileserver.conf.pid would prevent a clean restart of Samba.  We are also
> investigating to ensure the ACL model is indeed working as expected.
> 
> And the NTVFS file server has done us very, very well, and has generally
> had no complaints from users.  This 'just works' aspect of Samba4 has
> given users an incredible confidence in Samba 4.0 alphas, which is why
> we need to caution users that we know these are rougher waters. 
> 
> But we simply don't have the resources to continue developing two file
> servers, so we need anybody who is starting a new deployment to
> persevere with the new default, if possible, so we can gain confidence
> and remove these warnings.

In order to not let a bad impression prevail, let me mention
that the Samba developers have made a concious decision
to choose the proven and mature samba3 file server as the file
server for the 4.0 release, also in the AD-DC setup, so that we
only have to support and maintain one file server in future
production setups. For this purpose, the natural choice was the
s3 file server: It has been tuned and developed in a wide range
of production setups over many years. The ntvfs server, while
well integrated into the s4-ad-dc setup, well suited for that
limited scope, and newly written from ground up in a cleaner
design, was simply not ready to take over all the use cases for
the s3-file server due to a limited feature set.

So what I am trying to explain here is that the above mentioned
new "roughness" of the waters is not because the samba team has
made a silly decision to adopt a file server that is not as good
as the ntvfs server, but because the samba team has made the only
reasonable choice to use the more mature and feature-rich s3 file
server also for the ad-setup: The roughness is due to some
challenges in the integration of the s3 file server into s4
(via the "s3fs" method), and not beaucse the smbd file server as
such is bad.. :-)

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120703/74a6d794/attachment.pgp>