Controls the SAN File System volumes (disks) that a client can access.
>>-stfsdisk--+-------------------------------------------+------> +- -add--+-------------+--disk_file_name----+ | '-client_name-' | +- -remove--+-------------+--disk_file_name-+ | '-client_name-' | +- -query--+-------------+------------------+ | '-client_name-' | '- -discover--+-------------+---------------' '-client_name-' >--+-------------+---- -kmname--kernel_ext_name---------------->< '-client_name-'
This parameter causes the disk-discovery procedure to start. The procedure typically ends before the disk-discovery procedure completes. While the disk-discovery procedures are in progress, any file-system access that would fail because the virtual client cannot find a specific disk will wait until the disk-discovery procedure completes, and then proceed on the basis of the new disk-accessibility information.
The file-system driver is loaded as a kernel extension. To identify the instance of the file-system drive, you identify the kernel extension. The kernel-extension name is the same as the name and location of the file-system driver that was used to load the driver (for example, /usr/tank/client/bin/stfs for AIX®). Note that the kernel extension name might not be unique.
A client reads and writes files by accessing the disks on which the file data resides. To control which disks that a client can access, SAN File System identifies that disk by a SAN File System global disk identifier, and the disk-access subsystem associates that identifier with the name that the AIX operating system uses to identify that disk. The disk-access subsystem maintains a database that correlates global-disk identifiers with AIX device numbers. When the client needs to access a data block of a file, it consults that database.
The disk-access subsystem maintains the database by reading certain disks at certain times and looking for a SAN File System global disk identifier. If it finds the identifier, it determines whether the disk is a SAN File System user-data volume. If the disk is a volume, it adds the disk to its database.
The set of disks that the disk-access subsystem searches is called the disk-candidate list. The stfsclient command creates the disk-candidate list when it creates the virtual client. You can modify the list using the –add and –remove parameters.
The candidate-disk list is a list of unique disk-special file names. Because a disk can be referred to by more than one disk-special file name, the list is not strictly a list of unique devices. Actually examining disks and updating the database of valid user-data volumes is separate from maintaining the candidate-disk list.
When you add a disk to the candidate-disk list, the client immediately tries to read it and adds it to the database. But the disk becomes and stays a candidate regardless of the results of that operation.
You can force the client to rescan the entire list of candidate disks using the –discover parameter. The client updates its database of user-data volumes according to the results of this discovery, adding and removing disks as necessary. The results of the discovery do not affect the candidate-disk list, however.
Note that device file names can change as the client runs. Such a change has no effect on the client unless something causes a disk-discovery procedure to run. For example, if you add /dev/rhdisk35 as a candidate disk, and the client successfully identifies it as a SAN File System user-data volume, and then you delete /dev/rhdisk35, the client continues accessing that disk as before. The disk /dev/rhdisk35 continues to be a candidate. But the next time a disk-discovery procedure runs, the candidate will be found invalid and the client will no longer have access the disk.
stfsdisk -query -kmname /usr/tank/client/bin/stfs
Parent topic: AIX-client commands
Related reference
rmstclient
stfsclient
stfsdriver
stfsmount
stfsumount