Samba vs. NetAppliance

[Jeremy Allison]

Benn, Paul wrote:
> 
> > -----Original Message-----
> > From: Jeremy Allison [mailto:jallison at cthulhu.engr.sgi.com]
> 
> > My problem with your design (which I know quite a bit about,
> > funnily enough :-), is that it violates the principle of
> > least suprises for the nfs user. ie. They may get access
> > denied when the UNIX perms say they should be granted access.
> 
> But wouldn't it also be a "surprise" when an NFS user finds that she can't
> execute a file because one of the DOS bits was flipped on by a Windows user?

Indeed. Sharing metadata is always riskty. Of course this can be
prevented by the Samba admin also.

> Isn't it true that NFS clients don't always check for locks? So wouldn't it then
> be a "surprise" to a Windows user when an NFS user deletes or possibly corrupts
> a file that was supposed to be locked by the Windows user (non-Irix versions
> assumed - a majority of Samba versions according to the Samba survey)?

Arbitrary processes writing arbitrary data into a file of which they know
nothing of concurrent usage will corrupt data anyway, whether the OS
allows concurrent write during a read or not. UNIX applications designed
to operate in this environment use fcntl locking, which is (by design)
the same locking mechanism that Samba uses to map Windows locks onto.

You have no idea how long it actually took to create a realistic
test case to be able to scare customers with the "file corruption"
bugbear and to prove it was fixed by the kernel oplocks code just
to take advantage of your exact point in marketing slides :-). Most
apps just don't do this.

> Again, pardon my lack of UNIX knowledge but wouldn't POSIX ACLs hinder
> performance and don't some flavours of UNIX (e.g. Solaris) have their own
> incompatible-with-other-flavours ACLs? Why would you even bother with it until
> there was some sort of a standard (and who knows when that might be)?

Ah, a POSIX novice (the old proprietary, mother-knows-best argument :-).
As I think Dave C.B. has already pointed out, there is a standard for
POSIX ACLs, the main problem (for Samba at least) is that there isn't
a standard for the POSIX ACL *API*. However, we'll eventually muddle
through that in the same way we have to provide printing services,
browsing services, logon services and all the other things that a NetApp
box doesn't do :-).

As for the performance arguement, tell me - why would ACLs be slower
on Solaris (or IRIX for that matter) than they are on NT or WAFL 
(valid technical reasons only please :-) ?

> True, most NT software doesn't use the ACL design and most Windows users don't
> need to bother with ACLs. The NT administrators who set everything up need to
> though and they may have reason to setup complex ACLs, something that can't be
> done with UNIX file permissions.

Everything that can be done with NT ACLs can be done with POSIX ACLs.
Admittedly, not everything can be done with UNIX permissions only, but
the missing cases are rather baroque (and I would argue fairly uncommon
in the IT world).

> > This is a straw man. Have you looked at the Samba consultants list ?
> > This is also not even mentioning such companies as IBM & HP
> > who are now
> > supporting Linux (all versions of which include Samba), LinuxCare,
> > RedHat, Caldera and a host of other companies (I can't even remember
> > them all). Remember - every "Linux Certified Engineer" will also be
> > able to support Samba :-).
> 
> True but many of the settings can be done via a web browser by almost any
> network administrator that has little NetApp knowledge.

Oh, you mean like using "SWAT" :-).

> Combine the fact that a filer comes pretty much optimized right out of the box
> with the fact that it looks and feels like an NT4 member server to Windows
> clients and the fact that it can be administered with standard Windows NT tools
> (like server manager for setting up shares and share level ACLs, user manager
> for group membership and Explorer for ACLs and file access auditing). A large
> support infrastructure already exists in the form of Microsoft Certified
> Professionals for filers from this perspective (yes, there are a lot of
> paper-MCSEs out there will be paper-LCEs soon enough too).

Well that's just a difference in target market. CIFS Filers are designed to
go into Windows only environments (at least until Microsoft decides you
have no business being there. Good luck then :-). Samba is designed to
slot into mixed UNIX/Windows environments and to give control of the
file sharing back to the UNIX admins. And judging by the response to my
article in Microsoft Certified Professional magazine there are a
lot of NT admins who are *very* interested in becoming UNIX/Linux admins :-).

Cheers,

	Jeremy Allison,
	Samba Team.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------