Environments

The following are the platforms supported by FSR and the physical requirements of the target system.

Platforms

Works on Windows 2012 x64 or later, Linux CentOS 6.4, Ubuntu 16.04 LTS x64 or later platforms. The file system supports NTFS, ReFS, ext family (ext3 or higher), and xfs. (Old file systems such as FAT are not supported.)

CPU

Works with at least 2GHz, 4 core or higher x86/x64 compatible processor.

Memory

At least 1 GB of physical memory per resource is recommended for use as a memory buffer for replication.

Disk

The default installation size such as installation files and log files is 2GB, and a hard disk capacity of 10GB or more is required per resource for the file buffer.

How it works

It is based on active-passive clustering operation.
Supports one-way replication from primary to secondary nodes. Operating methods such as circular mirroring and dual primary mode are not supported.
Asynchronous replication is supported, but synchronous replication is not supported.

Functional scope

FSR basically aims to support replication for all file types and file I/O implemented in commercial file systems, but it is practically impossible to support all environments and file systems. We will expand the scope of support by first supporting the most used file systems and environments. And replication for some system files and special files is excluded from the support specification. The scope of the specific file replication function related to this will be described in detail according to the following classification.

File Types

The following file types are supported.

general files and directories
link files
- soft link
- hard link
- junction, reparse point
sparse file
compressed file
encrypted file

The following special files will be supported in FSR version 1.1.

NTFS ADS(Alternate Data Stream)
NTFS TxF(Transaction File)

When a user specifies a replication target for an FSR, care must be taken to ensure that system files used at the OS level are not specified as replication targets. Even if there is normally no problem in replicating system files, care must be taken as it can cause operational problems if a deadlock occurs occasionally due to contention with file I/O of the OS during synchronization or replication.

I/O Types

Most of the I/O types supported by Windows and Linux are supported.

General I/O
- Buffered I/O(Cached I/O)
- Direct I/O(Non-Cached I/O)
Memory Mapped I/O
Special I/O
- linux
  - Async I/O(aio)
  - Vector Write(writev)
  - Splice I/O
  - Uring I/O

Splice I/O in Linux is a special I/O that implements zero copy for high-speed data transfer. FSR can capture and replicate Splice I/O, but additional Copy Latency is required in the process of copying Splice I/O data for replication, resulting in performance degradation compared to original Splice I/O. This is an unavoidable technical limitation of implementing data replication. You should take this into account when replicating data from applications that use Splice I/O.

File Properties

Replicate the following file attributes.

File properties: read-only, hidden, system, directory, archive, sparse, compressed, encrypted
ACL: SID or account name of the source file
Time: modification time

It replicates most of the file attributes, but the file time attribute is only replicated for the modification time and not for other times. For example, it is technically impossible to match the file access times of the source and target.

Among the file attributes in Windows, the device attribute (FILE_ATTRIBUTE_DEVICE) and virtual attribute (FILE_ATTRIBUTE_VIRTUAL) are system-reserved attributes and are excluded from replication.
The following file attributes related to OneDrive added in Windows 10 are not supported.
- FILE_ATTRIBUTE_RECALL_ON_OPEN
- FILE_ATTRIBUTE_PINNED
- FILE_ATTRIBUTE_UNPINNED
- FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS

Shared Files

Fully real-time replication of files shared by Network File System (NFS) is subject to technical limitations. There is a limit to capturing real-time I/O just by filtering the local file system because the subject that changes the shared files can be multiple nodes.

Therefore, real-time replication is not implemented for shared files, and it is provided as a function to back up through periodic synchronization.