Steve Holdoway <[EMAIL PROTECTED]> wrote: > In a situation where both products will provide the same > functionality, one is used *in preference* to the other. That's > what the word means.
But they do _not_ provide the same functionality. SMB services present _different_ meta-data to the client than NFS. SMB presents clearly Windows client-centric meta-data and filesystem organization, especially FAT blocks. NFS presents clearly UNIX client-centric meta-data and filesystem organization, especially inode blocks. Now if you're just using them to copy files, that's fine. But we have other, non-filesystem protocols for that. Hence why these protocols are often use as a "local-like filesystem" with the applications directly accessing them. And that's when things break. GOLDEN RULE OF NETWORK FILESYSTEMS: Serve (and emulate on the _server_, if necessary) the filesystem that the mapping/mounting _client_ expects. If your client is Windows, serve SMB (including emulating SMB on the UNIX/Linux server). If your client is Linux, serve NFS (including emulating NFS on the UNIX/Linux server). If your client is UNIX, SMB is often _not_ an option at all. It's much easier for a servers to emulate a network filesystem protocol in a user-space service than it is for a client to translate a non-native protocol at its virtual filesystem (VFS) level, if it has one at all (or adds one). That's because all the server is doing is "sharing" the data, providing any locking or RPC mechanisms, etc... It's not running any "apps" in the emulation, any "apps" would be local and work on the "native" filesystem. But the client, on the other hand, _is_ running "apps" on the "translated" filesystem. Now in the case of SMB to Linux, you are _emulating_ on the server, then _translating_ on the client. Nuts! First off the SMBfs VFS layer has to "translate" inode functions into FAT, then it sends it up to the server, which "translates" it back from FAT to inode. Now Samba has some extensions to do this, but it's still not as "native" as NFS' inode-to-inode reality. In fact, Tridge & co. has constantly stated they need a native SMB kernel module for the _server_ to "hook into" filesystem operations like kernel NFS does. If you're SMB is Windows, which doesn't have the Samba extensions, and you're running SMBfs on the Linux client -- countless things "just break" (just like user-space NFS does versus kernel-space NFS). That's why _enterprise_ who have Linux workstations _must_ use NFS. And if you have UNIX workstations, well then, SMB is _not_ even an option. So unless you believe LPI should only cover Linux server-only environments, unlike HP, Red Hat, Sun and virtually every other UNIX/Linux certification program, NFS is a reality. The driver for NFSv4's augmented RPC capabilities are so massive by virtually every enterprise that it has been OSDL's major, non-Linux integration focuses for quite awhile now. Why? Because SMB is not even an option for virtually all non-Linux platforms. You want more Linux adopting in the enterprise? You show enterprises that Linux can really "serve it all" -- including replacing countless AIX, HP/UX and Solaris capabilities, or at least integrating natively with them. WHY ALL THIS IS MOOT? Many NFSv4 concepts and configurations are _concurrent_ with "advanced" Samba usage. E.g., with NFSv4, IDMAP is a _standard_ RPC service. It's the same service which Samba also uses -- whether it's connecting to ADS or an open LDAP tree (possibly with NSS capabilities, like Fedora DS). In fact, _unlike_ NFSv4 (which uses the _native_ GLibC functions), Samba requires an extra user-space service in Winbindd to handle several things: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html Same deal for authentication. NFSv4 offer a _standard_ RPC service to GSSAPI, a very flexible tie-in for authentication. Samba actually does as well. We can "tie-down" to common implementations, such as either Kerberos, or authentication against a LDAP tree (e.g., NSS). So when we do that for Samba, we do it for NFSv4 as well with just a few, added concepts to the objective. In a nutshell, these concepts are more "native" between Linux (kernel/GLibC) and NFSv4 and related RPC service than Samba's RPC services! That's why when you cover Samba authentication and object mapping, you basically cover the Linux capabilities that serve NFSv4's RPCs too. Now lastly, when it comes to Access Control Entries (ACEs), it's a little more murky. Unlike authentication and object mapping, where NFSv4 RPC and core Linux (kernel/GLibC) capabilities match, NFSv4 has its own, richer ACL (Access Control List) controls and ACE meta-data than the POSIX ACLs built into the Linux kernel (since 2.5.3+ development). The IETF is working on NFSv4 to POSIX ACLs mapping. So I stated unless a concept or configuration in NFSv4 RPC capability is directly shared with the underlying ACL support in the Ext3 (or XFS) filesystems, or a Samba ACL support configuration also addresses it, we should leave it for now. > In this case, samba can provide file sharing services to far more > clients than NFS, so is functionally (not technically!) a superset > of it. *INCORRECT* Please point me to the SMB _client_ support in several UNIX platforms? > And, because it grew up having learned the lessons of the > early versions NFS, people who suffered greatly through them are ( > with reason IMHO - remember what it was like 15 years ago??? ) > biased against it. Listen to yourself. Now apply the same to SMB. Ask yourself: Where was Server Message Block (SMB) 15 years ago? Now ask yourself: Where was SMB 10 years ago? And ask yourself one more question: Where was Samba's SMB support just 5 years ago? Ten (10) years ago Linux's NFSv2 implementation _sucked_, and _sucked_ hard. I will full admit that. It wasn't until the SGI Trond+Higgen patches in 2000 that started to address many things (and finally put in kernel 2.4.18 by Red Hat's Cox, although rather incompletely). At the same time, ten (10) years ago, Sun Solaris had NFSv3 support, including NIS+ tie-ins and other capabilities, but that wasn't Linux. Furthermore, just five (5) years ago, NFSv3 wasn't well implemented on Linux as other platforms, and there was a darth of specific implentations to address IETF options such as authentication, authorization, mapping and other real-time (RPC-time) services. Few Linux vendors, like Red Hat, only offered mount-time or initial user access-time Kerberos authentication. Linux was still not "on-par" with even Solaris, and most other commercial implementations. And Sun even offered it's Sun One network infrastructure, including NSS LDAP at its core. Which is why, five (5) years ago, Sun got serious about making a true UNIX-Linux infrastructure with true, UNIX-Linux native network file services. It _knew_ the key to that was Linux. Almost three (3) years ago, we got NFSv4 for the GPL Linux kernel with GPL user-space services. Leveraging existing GSSAPI, the same IDMAP services that Samba 3.0 was also leveraging, etc... In fact, OSDL's efforts are more about non-Linux than Linux. SMB does _not_ solve the network filesystem need for most UNIX platforms. Linux is already the "concentration point" for Windows servers, and the _key_ to open enterprises is a Linux platform that addresses *ALL* enterprise platform needs. > Stop jumping down everyone's throats. I'm sorry if I'm "jumping down everyone's throats" with the reality of what _enterprises_ are actually deploying! > Do you think your .sig allows you to do that? Yes! I am a "professional, technical annoyance." That's because I point out the obviousness of the truth of enterprises. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-discuss mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-discuss
