Mounts the global namespace.
>>-stfsmount--+-------------+--mount_point--+------------+------> '-client_name-' +- -readonly-+ '- -ro-------' >--+---------+--+----------+--+----------+--+-----------+-------> '- -quiet-' '- -nosuid-' '- -noexec-' '- -noatime-' >--+--------------+--+---------------+--------------------------> '- -nodiratime-' '- -synchronous-' >--+-------------------------+--+----------------+--------------> '- -mandatory_range_locks-' '- -dac_override-' >--+------------------+--+------------------+-------------------> '- –uid_owner--uid-' '- -gid_owner--gid-' >--+----------------+--+------------------------------+---------> '- -fstype--name-' '- -standindevice--device_name-' >--+----------+------------------------------------------------>< '- -nomtab-'
Without this parameter, system calls return as soon as the changes are stored in kernel-cache memory, and the changes are committed to storage some time later (automatically or by user request with the /bin/sync command).
Without this parameter, all range locks set or seen through the global namespace image are advisory, as defined by POSIX. This means that you can lock a range of a file, but no one has to respect that lock, and you do not have to respect anyone else's locks.
With the parameter, some range locks can be mandatory to an extent. Range locks do not have an advisory or mandatory state. But when you access a range of a file that is locked, Linux™ treats the lock as mandatory or advisory depending on whether the file image that you access is in mandatory or advisory range lock mode. A file image is in mandatory-range-lock mode if it was created while the global namespace image had mandatory range locks allowed and the file had the set group ID flag on and the group execute flag off.
Mandatory range locks are considered mandatory only with respect to a particular global namespace image.
A client does not know whether another client considers a lock mandatory or advisory. So, if you access a file using multiple processes on the same system, through the same global namespace image, mandatory locks are fully mandatory. But another client, or even a process accessing the same client from a different global namespace image, is free to consider the locks advisory.
When the owning group of a file changes, its set group ID flag gets turned off, and range locks are no longer mandatory. This is normal behavior for the set group ID flag, but in many Linux file-system types, it is suspended for the special case of the set group ID flag that means mandatory range lock. SAN File System does make that special exception because the flag does not have the same meaning on non-Linux client. Note, that as with any Linux mandatory range lock, they do not restrict access to the file using a private mmap.
You can change the mandatory-range-locks-allowed status of a global namespace image by remounting.
The mandatory-range-lock status takes effect when a file is opened. Changing the mandatory-range-lock attribute for the global namespace image after you open the file does not change the file's status. For example, if you have a file open with mandatory range locks allowed, and then you disallow mandatory range locks, all locks on that file, including subsequent ones, are still mandatory until you close the file.
If not specified, the global namespace image uses the real owner user ID stored in the file system.
If you do not specify a file-system-type name, the system defaults to the file-system-type named "stfs".
Use this parameter only when you load multiple instances of the file-system driver on the same client system.
In order to make Linux NFS export SAN File System files, the file-system type presents itself to Linux as a device-based file-system type, as opposed to a network file-system, such as NFS. But because the global namespace does not actually live on a device (it lives on a collection of devices and a metadata server), a block device must stand in for the global namespace wherever it makes a difference. Accordingly, every global namespace image is associated with a block device, known as the standin block device. The file-system driver contains a block-device driver and constitutes a set of very simple block devices whose only job is to be standin block devices. They cannot be used for anything. If you exports SAN File System files from NFS, make sure you do not use the same standin block device for two different SAN File Systems (at different times).
Note that the device is identified with the global namespace image by device number, not by the device-specific file name. You can delete the device-specific file after the stfsmount command completes.
The value of this parameter is what shows up as the file-system identifier in the Linux mount table listing in /proc/mounts.
You can create a block-device-specific file using the Linux mknod command.
If not specified, the stfsmount command uses an unused standin block device. It creates a temporary block-device-specific file for it and adds the name of that temporary file to the Linux mount table. It creates the file in the directory defined by the TMPDIR environment variable, or /tmp if TMPDIR is not defined. It uses a lock file to prevent two processes that are simultaneously running the stfsmount command from choosing the same unused standin block device. It creates that file in the same temporary directory as the block-device-specific file.
If not specified, the stfsmount command adds an entry to the /etc/mtab file describing the global namespace image if the mount is successful. It then locks the file using the /etc/mtab~ lock file while it attempts the mount and updates /etc/mtab. If specified, this command does not attempt to lock or update /etc/mtab.
Note that /etc/mtab is obsolete and would only need to be updated if it might be referenced by existing applications. /proc/mounts contains more reliable information, straight from the kernel itself.
You must have root privileges to use this command.
This command creates an image of the global namespace on the client system by mounting a directory. When a client mounts a directory in the global namespace, that directory and its subdirectories become part of the client's directory hierarchy.
Before you can mount the global namespace, you must have a virtual client running on the client system. To create the virtual client, use the stfsclient –create command.
Remounting the global namespace image is not the same as unmounting the global namespace and then mounting it again. Rather, it changes the attributes of an existing global namespace image, such as changing from read-write to read-only mode. To remount the global namespace image you can use the Linux mount command.
To unmount the global namespace, use the Linux umount command.
stfsmount /mnt/sanfs -fstype sanfs
Parent topic: Linux-client commands
Related tasks
Starting a Linux client