NSS uses barrier flushes to ensure that metadata has actually been written on devices that cache writes and mis-inform the file system that the I/O has completed. Using barrier flushes helps prevent data corruption that can occur during a system crash because all confirmed writes are actually known to be on the device. This works as expected on physical devices.
Xen-based file-backed block devices do not support barrier flushes in the Xen version released in OES 2 Linux. If the system crashes, data corruption can occur because the flushes are not actually performed. We recommend against using file-backed devices for virtual machines. For information, see Section 6.1.2, Virtual Machine Issues.
You can determine whether NSS is using barrier flushes by looking for the following lines in the /_admin/Manage_NSS/Pool/poolname/ZLSS/PhysicalIO.xml file:
<barrierSetting value="1"/> <barrierCommandLine value="1"/> <barrierFlushes value="673"/>
If the barrierSetting value is true (1), then the pool is currently using barriers.
The barrierCommand value indicates whether the user turned off barriers when mounting the pool.
The barrierFlushes value is a persistent count of the number of times a barrier flush has been called, including calls that get returns of Not Supported.