On 9 Dec 2004, at 12:07, Michael Lueck wrote:
Let's think Linux/Unix here a second. Preference files are stored in the user's home dir. A user can log in (text or X) multiple times, they will always get the same home dir. Thus each login instance will share those config files.
The same just happens to be true of Windows clients logging into a Linux box ala Samba PDC.
The two are not the same.
When you log in remotely to a unix-like system, you're using files in the one home directory, on one central file system. If you log in to a workstation that has NFS-mounted the remote directory, the same holds true - the files you edit are those present on the remote/central file system.
When you log in to a Microsoft Windows client with roaming profiles enabled, the client will copy all of the files in your "profile" across to the local file system. You edit them in place on the local file system. Then when you log off, the files are copied back to the "profile" directory. There is no rsync or other optimisation - if you have 200MB of files in your profile, that 200MB will be copied back and forth every time you log in and log out.
The two approaches have their advantages and disadvantages. In the case of the unix-like with home directories mounted over NFS, you don't want to be using KDE3 and Konqueror (for example), since Konqueror will check it's on-(NFS-)disk cache for the latest version of a file, find it's outdated, download the new file from the web server, save it to the on-(NFS-)disk cache, then display it to the user. Thus the main disadvantages of the remote/central disk method are the dependence (utter and absolute) on the remote hard disk, and the intermediate network. If either of those should stall, all machines on the network will halt as the NFS client waits for responses to NFS I/O.
The main disadvantage of the Microsoft Windows approach is the bandwidth wasted while people log in and out.
Both methods "need to be fixed" IMHO - a fair middle ground would be to mark some portions of the "profile" as "volatile" (and thus they won't be copied back to the central store on logout), and the actual copying back and forth of non-volatile (I'm not going to use the word "permanent") data should use an optimised copy - something like rsync, which will only copy the changes. This means you can feasibly run a 100-workstation network on 100Mbps Ethernet - no need for Gigabit unless you actually have to transfer tens of thousands of rendered frames of movies across the network (or you absolutely must have sub-millisecond timing on communications, or...) (and assuming that everyone doesn't try to log in at the same second).
Alex
PS: Of course, there are people out there who will tell you to get diskless workstations, and trust the network and server hardware to up to snuff. But they tend to have more money to spend than I do, and don't seem to care that a local file system is faster than a network mounted file system ;) (it helps to have bug-free chipsets on the servers, too) (and now I don my flame-retardant suit, and bring out the sun lamp)
PGP.sig
Description: This is a digitally signed message part
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
