File system characteristics necessary for successful IBM Data Replication deployments

To successfully deploy IBM® Data Replication onto a particular file system, the file system must conform to certain expectations. Specific file systems are discussed as exemplars but the list should not be considered exhaustive. The intention is to characterize required behaviors rather than list supported file systems.

Consistency

IBM Data Replication requires that a file system provide semantics that guarantee a view of the file data and metadata that is consistent between all writers and readers. File metadata includes such information as its existence, its size, and various timestamps.

Directly attached local disks typically provide these semantics. Examples of file systems that are deployed on local disks that exhibit the required behavior include JFS, NTFS, ext3/ext4, and UFS.

When mounting remote disks such as through CIFS, also known as SMB or Windows File Share, NFS, or SAN, the consistency requirements must be maintained. This means that any caching, whether at the database, operating system, file system, or disk hardware levels, must provide this level of consistency. NFS 3 and 4 deployments ensure file metadata consistency through the use of mount options such as “noac” or “actimeo=0,” depending on the operating system.

One special point of caution is the use of directio on Linux®. Linux provides consistency only between writers and readers using directio. For example, consistency is not maintained if the writer is using directio and the reader is not. IBM Data Replication for Oracle databases and IBM Data Replication for Sybase databases are enhanced specifically to address the use of directio on Linux.

Symptoms of consistency failure

When the required consistency semantics are not maintained, IBM Data Replication has been known to fail with the following non-exhaustive list of symptoms:

  • IBM Data Replication reports that a database log file:
    • Cannot be found.
    • Cannot be read.
    • Returns inconsistent results when read.
    • Is the wrong size.
  • IBM Data Replication hangs when it tries to read a database log file.

Locking

Under certain conditions IBM Data Replication must lock a file. The file system must ensure that it provides proper locking semantics. Specifically, it must permit portions of a file to be locked, such as is typically implemented by the POSIX fcntl() system call. Whole file locking, such as that provided by flock() system calls, is not sufficient.

Symptoms of lock failure

When the required locking semantics are not maintained, IBM Data Replication can fail with the following non-exhaustive list of symptoms:

  • IBM Data Replication metadata is corrupted.
    • IBM Data Replication cannot prevent multiple instantiations of the same IBM Data Replication instance from operating.
    • IBM Data Replication cannot work correctly in a fail-over scenario.
  • IBM Data Replication cannot start because it cannot lock its metadata files.

Examples of unsupported file system configurations

This is a non-exhaustive list of file system configurations that are either unsupported or supported with limitations:

  • NFS configurations without “noac” or “actimeo=0” mount options enabled. These configurations do not meet IBM Data Replication consistency requirements.
  • OCFS2: Locking semantics do not meet IBM Data Replication requirements. IBM Data Replication can read database log files stored on OCFS2 but IBM Data Replication should not be installed on an OCFS2 file system.
  • Microsoft SQL Server deployed with database disk caching enabled: Does not meet IBM Data Replication consistency requirements.
  • AFS® : Locking semantics do not meet IBM Data Replication requirements.