How do I ensure that data is securely and reliably written to disk?

https://access.redhat.com/solutions/43912

 SOLUTION 已验证 - 已更新 2014年六月19日22:32 - 

English 

环境

• Red Hat Enterprise Linux 4
• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 6

问题

• It is important for many applications to ensure that data is safely written to the disk and that in the event of a power failure the data would still be there when power is restored. Data can be written out as part of a transaction with another data source and once it is written to disk the data is deleted from the data source. Therefore, it is imperative to know that the information is secure on the disk, otherwise the data could be lost forever.

决议

There are 3 levels of caching involved in writes to disk in Red Hat Enterprise Linux :

1. Application caching in Glibc :

• Here a successful completion of fflush() should guarantee that the data is out of user space. But, you still have to worry about power failure, kernel error, disk-system caches when this occurs.

2. File system caching:

• The file system holds information in memory (kernel page cache) before committing to disk. This can be flushed to hardware using the fsync() call.
• You can chose to use O_DIRECT. This will bypass the filesystem cache leaving the application to mange the cache itself. Databases use this interface but there have been issues with this interface. See this link for more details.

3. Hardware caching:

• The hardware can cache file write operations before physically writing to disk. Write caching can be disabled on some drives :

  • IDE drives can be queried using hdparm -I; write caching is enabled if there is a * next to Write cache. hdparm -W can be used to turn off write caching.
  • SCSI drives can be queried using sdparm. Use sdparm --get=WCE to check whether the write cache is enabled and sdparm --clear=WCEto disable it.

• See the following discussions on the Postgress project for more reading on dealing with this :

  • Reliability
  • Reliable writes

• Another option is to enable write barriers in the file system. But there have been big performance issues with barriers. See here and here for more information on write barriers.

An application that is sensitive to data integrity should use our supported file system mode - data ordered mode - and using fsync() on the file when you want data to persist. We do support O_DIRECT, but that is more complex to get right. You also need to understand your storage and how it works - you can definitely lose data even if you do everything right in the app & we do it right in the kernel, but the storage is misconfigured or buggy.