When McKusick et al were designing the original HFS filesystem, the speed (measured in Revolutions Per Minute = RPM ) of FAST disk was of the order of 800 “120000 RPM . A rotational delay was introduced into the filesystem to take into account the slow rotational speed and slow transfer times of the underlying disk hardware. With a rotational delay between successive read and writes , the disk platter would be allowed to spin to an optimal position before the next data block was read from/written to disk. Without a rotational delay, successive reads and writes would find the disk platter at different positions on each successive read/write. This would result in successive data blocks being spread over the entire surface of the disk in a less-than -optimal pattern. Retrieving data that is spread out in this fashion would significantly hamper the overall IO performance of the filesystem.
The rotational speed and transfer times of modern disks are such that a delay between successive reads and writes makes no sense. A rotational delay of 0ms means that successive IO are sent immediately to the disk subsystem. Today's disk technologies have sufficient speeds to accommodate such requests .
A2:
The command sequence is valid although it will create a continuous "loop" of symbolic links. The cat command will fail with an error similar to "cat: Cannot open /data1/fileA: Too many levels of symbolic links" .
A3:
VxFS snapshots require a STATIC image of the data. If a data block changes in the original filesystem, the original block is first written to the snapshot filesystem. This will have an impact on the overall IO requests sent to the original filesystem. This will have a direct impact on the IO performance of the original filesystem. Only when the original block has been written to the snapshot filesystem can the backup proceed. Having the snapshot filesystem housed on fast, separate disks is a good idea in itself. The problem is the way that VxFS maintains a STATIC image of the original filesystem, i.e., copy the original block to the snapshot filesystem before updating the block concerned . This imposes additional IO on the original filesystem and adds additional IO requests to the system as a whole. Consequently, it is not surprising that the backup takes longer than when it had exclusive access to the data.
A4:
Because you have a "basic" understanding of the IO characteristics of the associated application and are ultimately not involved in the makeup of the underlying volume, I would consider not tuning the filesystem at this time. First, a detailed analysis of the IO characteristics of the associated application is necessary: Is the application performing sequential, random, logical, physical IO? How is the underlying volume constructed ? How many disks are used in the RAID 5 stripe set? How many parity disks are used? All these questions (and many more) need to be answered before considering tuning a specific filesystem.
A5:
For the integrity of the data, I would use the following options:
log, nodatainlog
For the security requirements of the organization, I would use the following option:
blkclear
Because the application is performing its own internal buffering and issuing write requests when it deems it necessary, there is little point in using the operating system buffer cache. This would only introduce an additional level of buffering, which is unnecessary. The mount option to use in this instance is:
