|
|
|
|
|
In tmplog mode, the effects of system calls have persistence guarantees that are similar to those in delaylog mode. In addition, enhanced flushing of delayed extending writes is disabled, which results in better performance but increases the chances of data being lost or uninitialized data appearing in a file that was being actively written at the time of a system failure. This mode is only recommended for temporary file systems. Fast file system recovery works with this mode.
Note
The term "effects of system calls" refers to changes to file system data and metadata caused by the system call, excluding changes to st_atime.
See the stat(2) manual page).
In all logging modes, VxFS is fully POSIX compliant. The effects of the fsync(2)and fdatasync(2) system calls are guaranteed to be persistent once the calls return. The persistence guarantees for data or metadata modified by write(2), writev(2), or pwrite(2) are not affected by the logging mount options. The effects of these system calls are guaranteed to be persistent only if the O_SYNC, O_DSYNC, VX_DSYNC, or VX_DIRECT flag, as modified by the convosync= mount option, has been specified for the file descriptor.
The behavior of NFS servers on a VxFS file system is unaffected by the log and tmplog mount options, but not delaylog. In all cases except for tmplog, VxFS complies with the persistency requirements of the NFS v2 and NFS v3 standard.
Unless a UNIX application has been developed specifically for the VxFS file system in log mode, it will expect the persistence guarantees offered by most other file systems and will experience improved robustness when used with a VxFS file system mounted in delaylog mode. Applications that expect better persistence guarantees than that offered by most other file systems can benefit from the log, mincache=, and closesync mount options. However, most commercially available applications will work well with the default VxFS mount options, including the delaylog mode.