FAQ

Frequently Ask Questions

1. Bandwidth Requirement

Q: What is the bandwidth assumption for the product?

A: The bandwidth requirement depends on the data update frequency. All local updated information is forwarded to the remote mirror server, so to estimate your bandwidth requirement, add 20% to your total data update rate, to account for overhead.

For example, if your data update rate on a dedicated connection is around

200MB per hour, the total bandwidth consumption should be:

200(MB) x 8(bits) x 0.8(80%) / 3600sec = 512kbps

Of course, if you use the Internet as the transport, the result will vary.

2. Distance

Q: How far can the two MFS Servers be separated physically?

A: The distance limit is based on the latency between the mirrored servers. MFS uses NFS as its transport layer, so as long as NFS can connect and move data between two servers, it will be fine for MFS.

3. Disk and Storage Requirements

Q: Do the two MFS servers need to have same type of disk and storage systems for their file systems?

A: MFS servers accommodate disk and storage media of different sizes and types from different manufacturers.

4. Server Type Requirements

Q: Do the two MFS servers need to be of the same type running same OS?

A: For the Clustering Plus product, yes, the two servers need to be of the same type running on same OS.

For the Replication Plus product, however, the two servers can be of different types as long as they support NFS.

5. File System Size

Q: Do the file systems on two MFS servers need to be the same size?

A: No, they can be different sizes.

6. Mirroring Granularity

Q: Do you have to mirror the entire file system between two MFS servers?

A: No, you do not have to mirror the entire file system; you can choose to mirror any directory in the file system if that is your preference.

7. Performance

Q: What performance overhead does the product introduce?

A: The maximum overhead is about 20%, in most cases, it is somewhat less.

8. Synchronization

Q: What happens when the replicated system fails? Does it synchronize when it comes back online?

A: The MFS Mysnc utility program logs the file path name when a failure occurs during a write operation to remote replicated MFS server. When the remote replicated server comes back online, Msync goes through all the files in the log file and re-synchronizes the remote files with the master files.

9. Application Transparency

Q: Do applications need to re-compile and re-link with a special library in order to use the MFS?

A: No, applications do not need to re-compile or re-link.

Actually, applications are not even aware that the MFS is handling all file mirroring for them in the kernel. Applications continue to access files with the same path name they are accustomed to using. There is no need to create symbolic links or new path names for existing files.

10. Replicated File System Readiness

Q: Are the files in the replicated file system (EXT3 or UFS) on the remote MFS server ready to use?

A: Yes, the files in the replicated file system, in either active-active or active-passive configuration, are ready to be accessed by local applications and clients.

Because MFS replicates on the file system level, the replicated file system (EXT3 or UFS) is already mounted and contains all information about newly replicated data and files; all its data and files are ready to be accessed. (This is a big advantage of MFS over other replication products.)

11. Transaction Awareness

Q: When replication fails due to a transmission error or other system problems, how do we know what data and files are impaired?

A: Because the replication unit is on the file, only the specific file is impaired, not the entire file system or entire disk or storage system. This makes it much easier to track down which file is impaired and recover it easily.

12. Ease of Use

Q: How complicated is it, and how long does it take, to install and run the software?

A: The MFS is designed to be easy to use. It takes less than 10 minutes to install, configure, and run the MFS.

The system administrator needs only to mount a shared (exported) file system from a remote MFS server onto a directory of a local file system (EXT3 or UFS). The syntax and semantics are very similar to NFS; it is just like mounting an NFS from a server to a local directory.

13. Windows Applications

Q: Does MFS support Microsoft Windows applications?

A: Yes. Microsoft Windows applications can be run from a laptop or desktop that accesses MFS servers as a client through SAMBA.

14. Single system real-time backup

Q: I only have one system, can I back up my files to another directory?

A. Yes. You can export the backup directory by putting it as an entry in /etc/exports file and start he nfs daemon. Then MFS mount the backup directory on the directory that to be back up.

# mount -t mfs localhost:/backup /home/mydirectory