Saturday, April 26, 2008

Protocol Negotiation and Session Setup continue…

Readingand Writing

The SMB protocol uses the READ and WRITE message types to perform I/O operations on a file for the client. Using the READ request, a client can request that the server return information from the file by specifying a number of bytes and an offset into the file. The server returns the data, indicating the actual number of bytes returned, which can be less than requested if the user tries to read past the end of a file.

The WRITE command updates a file in a similar manner. The client sends in the data that will be written, indicating the number of bytes to write and an offset into the file where the write operation will begin. If the request causes a write past the end of the file, the file is extended to make it larger. The server sends a response telling the client the number of bytes that were written. If the number is less than the requested value, an error has occurred.

Internet 2010

To increase read/write performance, the READ_RAW and WRITE_RAW message types can be used to exchange much larger blocks of information between the client and the server. When these are used, the client must have only one request issued to the server. In one send, the server will respond with data that can be as many as 65,535 bytes in length. The WRITE command works in the opposite direction, allowing the client to send a large buffer of raw data to the server for a write operation.

Locking Mechanisms

Locking allows a particular client exclusive access to a file or a part of a file when it is shared on th network. In SMB, the capability to create a lock is called an opportunistic lock, or oplock for short. This is better explained by looking at the way in which it works. A client can create a lock on a resource using three kinds of locks. The first is an exclusive lock, in which the client has exclusive access to the data held by the lock. A batch oplock is one that is kept open by the server when the client process has already closed the file. A Level II oplock is one in which there can be multiple readers of the same file.

The locking process consists of the client requesting the type of lock it wants when it opens the file. The server replies to the client with the type of lock that was granted when it responds to the open request.

A lock gives the client the capability to efficiently manage buffer space it uses when accessing a file over the network. For example, if a client has exclusive access to a file and is performing writes to it, it can buffer a lot of the newly written information before having to send it to the server to update the file. This can provide a reduced number of network packets when updating a file. A client that has an exclusive lock on a file can also buffer read-ahead data to make reading a file much faster.

These locks are called opportunistic locks for a reason. A client can be granted exclusive access to a file if no other client has it open at the time of the request. What happens when another client needs to read the file? The server notifies the first client that it needs to break the exclusive lock. The client then flushes its buffers so that any data that has not been written to the file is processed. The client then sends an acknowledgment to the server that it recognizes that the exclusive lock has been broken.

Batch oplocks are used to reduce the amount of traffic on the network when some programs require continual reopening of a file to obtain commands, as when a batch command procedure is executed.

For example, a batch procedure executed by the command processor usually opens a file, locates the next line to be executed, reads that line, closes the file, and then executes the command. The problem with this is that these steps are taken for each command line in the procedure, resulting in multiple file open/closes that are not really necessary.

This procedure for reading individual lines from a file is done by using a batch oplock whereby the client can read the data from its local read-ahead cache instead of reopening the file on the remote server to get each line.

Level II oplocks were new with the NT changes to SMB. This kind of lock allows more than one client to have a file opened for reading. When a client must read from a file that is opened by another exclusively, the server informs the current client that its exclusive lock has been broken and is now a Level II oplock. No client that has a Level II oplock will buffer data to or from the file. Thus, after the lock has changed to a Level II oplock (and the first client has flushed any data in its buffers), both clients can continue reading the file.

Friday, April 25, 2008

Protocol Negotiation and Session Setup

SMB has a built-in mechanism that is used by the client and server to determine the other's capabilities so that a common protocol version can be established that the two will use for the network con• nection. The first SMB message that the client sends to the server is one of the SMB_COM_NEGOTIATE type. The client uses this message to send the server a list of the dialects it understands. The server selects the most recent dialect it understands from the client's list and returns a message to it.

The response the server returns depends on the type of client. The information includes the dialect selected and can include additional information, such as buffer sizes, supported access modes, time and date values, and security information. After the client receives this response, it can continue to set up the session by using the SESSION_SETUP_ANDX message type.

Internet 2010

If the initial server response indicates that user-level security is being used, this message type can be used to perform a user logon. The client sets a value in the message header called the UID (user ID) for the account it wants to use. It also supplies the account name and password to the server by using this message type. If these values are validated by the server, the user can continue to use the UID to make subsequent accesses.

Other setup functions that are performed by using SESSION_SETUP_ANDX include the following:

  • Set the maximum values for the size of buffers that will be used in the message exchange.
  • Set the maximum number of client requests that can be outstanding at the server.
  • Set the virtual circuit (VC) number.

If the VC passed to the server is zero and the server has other circuits open for the client, it will abort those services, assuming that the client has rebooted without freeing those services first. To properly close a session, the client uses the message type LOGOFF_ANDX, which causes the server to close all files associated with the user's UID.

Accessing Files

Other SMB message types are used to traverse the resource directory and to open, read, write, and close files. First, the user must connect to the resource by using the TREE_CONNECT message. The mes‑

sage includes the name of the resource (server and share name) and, for earlier clients that do not perform logons, a shared password. The server responds by sending the user a value called the TID (Tree ID), which will be used in SMBs exchanged for this connection.

After the connection has been established, several basic SMB command formats can be used to manipulate files and directories that reside on the share. For example, the CREATE_DIRECTORY message is used to create a new directory in the file share's directory structure. The client passes the pathname for the new directory, and the server creates the directory, provided that the client has the appropriate access rights or permissions. The DELETE_DIRECTORY SMB message can be used to remove a directory, again based on the functions allowed for the username.

Opening and Closing Files

The OPEN message is used by a client to open a file. The path for the file is given, relative to the file share root. The client specifies the access that is desired, such as read, write, or share. If the file is successfully opened, the server returns a File ID (FID) to the client, which is used to further access the file using other SMB message types; it is similar to a file handle, which most programmers will recognize.

The server also returns data to the client indicating the actual access that was granted, which is read- only, write-only, or read/write. The CLOSE message is sent by the client to tell the server to release any locks held on the resource fileheld by the client. After this message, the client can no longer use the FID to access the file, but it must instead reopen the file and obtain a new value.

When a client does not know the exact name of a file that it wants to open, the SEARCH message can be used to perform a directory lookup. This function enables wildcards to be used, and the server response can include more than one filename that matches the request.

NFS Client Daemons

On the client side of the NFS process, there are actually three daemon processes that are used. The first is biod, which stands for block input/output daemon. This daemon processes the input/output with the NFS server on behalf of the user process that is making requests of the remote file system. If you use NFS heavily on a client, you can improve performance by starting up more than one bind daemon. The syntax used to start the daemon is as follows:

/etc/biod [number of daemon processes]

This daemon is usually started in the / et cIrc. local startup file. Modify this file if you want to permanently change the number of daemons running on the client system. You can first test by executing the command online to determine how many daemons you need to start and then place the necessary commands in the startup file.

When deciding performance issues, remember that on a heavily loaded client, making a change in one place might result in poorer performance from another part of the system. So don't assume that you need a lot of extra daemons running unless you can first show that they are needed and do improve performance. Each daemon process is like any other process running on the system, and it uses up system resources, especially memory. Begin by using one or two daemons if you are using a workstation dedicated to one user. For a multiple-user computer, test your performance by increasing the number of daemons until NFS performance is satisfactory (all the time checking, of course, other performance indicators to be sure that the overall system impact is justified).

Internet 2010

Although having multiple daemons means that NFS requests can be processed in parallel, remember that the network itself might be a bottleneck. Additional biod daemons will not increase throughput when the network itself is the limiting factor.

Also note that the biod daemon is a client process. You should not run it on an NFS server unless that server is also a client of another NFS server.

In addition to the biod daemon, the lock d and st at d daemons also run on the client

The mount Command

The mount command is used to mount a local file system, and you can also use the command to mount a remote NFS file system. The syntax for using mount to make available a file system being exported by an NFS server is as follows:

mount -F nfs -o options machine:filesystem mountpoint

In some versions of Unix, the syntax for mounting a remote NFS file system is a little different. For example, in SCO Unix you use a lowercase f and an uppercase NFS:

mount -f NFS -o options machine:filesystem mountpoint

In BSD Unix, there is a command called mount nf s, which uses the system call mount to perform most of its functions. This version of the mount command comes with a lot of additional parameters, including the capability to specify on the mount command line whether to use UPD or TCP as the underlying transport mechanism.

The value you supply for machine: filesystem should be the hostname of the remote server that is exporting the file system you want to mount for machine. Substitute the name of the file system for filesystem. The following example causes the remote file system on host zira, called /usr/ projectx/docs, to be made accessible in the local file system hierarchy at the /usr /docs directory:

mount -Fnfs -oro zira:usr/projectx/docs /usr/docs

This is the same way you mount other local file systems into the local hierarchy. Under the / us r/docs directory, you can access any other subdirectories that exist on host zira under the /usr/projectx/docs directory.

The -o parameter can be used to specify options for the mount command. In the preceding example, the letters ro for the option were used to make the remote file system read-only by users on the local computer.

Other options that can be used when mounting a remote file system include the following:

For more command-line parameters and options, see the man page for the mount command for your particular system.

The mountpoint is the path to the location in the local file system where the remote NFS file system will appear, and this path must exist before the mount command is issued. Any files existing in the mountpoint directory will no longer be accessible to users after a remote file system is attached to the directory with the mount command, so do not use just any directory. Note that the files are not lost. They reappear when the remote file system is unmounted.

Using the fstab File to Mount File Systems at Boot Time

When you have file systems that need to be remounted each time the system reboots, you can use the file /etc/fstab to do this. This file is also used to mount local file systems, so be careful when making edits. The format for a record is as follows:

filesystem directoryname type options frequency pass

The filesystem field for a record used to mount a remote file system includes the server hostname and the pathname of the remote file system separated by a colon (hostname: path ). The second field, directoryname, is the path for the mountpoint on the local system, which indicates where the remote system is mounted and made available for access. The next field, type, is used to specify the file- system type, which can be any of the following:

The options field is used for a comma-delimited list of mounting options (rw, ro, and so on). The frequency is used in determining when a file system will be "dumped" for backup purposes. This can usually be set to zero for NFS systems mounted on a client because it is usually the NFS server that is responsible for making backups of local data. The final field, pass, can also be set to zero most of the time for an NFS file system mounted on a client. This field is used by the f sck utility to determine on which pass it is to check this file system.

Thursday, April 24, 2008

Microsoft Distributed File System (DFS) continue...

Creating a DFS Root

Creating a DFS tree is not a complicated task when using a graphical interface such as the one provided by the MMC and by the wizards that walk you through setting up your file system. To create a new DFS root, use the following steps:

  1. Click Start, Programs (All Programs for Windows Server 2003), Administrative Tools, Distributed File System.
  2. When the management console appears, select New Root from the Action menu. A wizard pops up. Click Next.
  3. You can select to create a file system that makes use of the Active Directory for storing the DFS configuration information. You can also select to not use the Active Directory. For the purposes of this example, I've chosen to not use the Active Directory. After making the selection, click Next.
  4. The next dialog box prompts you to enter the name of the server that will host the distributed file system. The default is usually the server on which you are running the wizard. Use the default or enter another server. Click Next to continue.
  5. The wizard next prompts you to enter the name of the new root DFS file system. Note that what you enter here shows up in the field Share to Be Used at the bottom of the dialog box. You can use the name of an existing share in the Root Name field, or create the share to be used after you complete this wizard.

6. If you entered a share that does not yet exist, you can now choose the folder to share by entering it in the field or by using the Browse button.

Internet 2010

7. Finally, the wizard displays a summary of the information you have entered. Click the Finish button to complete the process of creating the new DFS root.

Adding Links to the DFS Root

After you've created the initial root for your file system, you can add one or more links. Links, as yo will recall, are actual directories (or folders, depending on which terminology you prefer) that will be accessible from your DFS root.

DFS is a domain-wide file system. You can easily browse a file share located on another server in the domain. Thus, you can hide the physical location of files from users. Instead of having to remember servers and share names, the user only has to remember the share name. Because the share name is domain-wide, you can't use the same share name on one server that you do on another. Users can then simply connect to the share \ \domainname\share. They don't need to know the server names on which the actual folders in this share are located.

You can use the Action menu to add or delete a DFS root. You can also use the Action menu to manage links and replication.

DFS does not add any additional security features to the file system. Instead, the usual rights and permissions that are already in place on the server are used when evaluating a client's access to a file or directory in the DFS tree.

One major difference between NFS and DFS is that DFS is built using SMB messaging techniques for the most part and is not compatible with all NFS servers. If you have a mixed-environment network in which most of your data files are offered via NFS on Unix servers, it would be more economical to acquire PC-based NFS client software than it would be to replace all your existing servers with NT DFS servers.

Internet Blogosphere