Database And Brain

My latest column, titled "Lying Computer" was up today.

It's about "sync", which flushes buffers in memory and write to disk physically, then synchronized the state in memory with one on file. It is not done by one single component, but done in relay. It should work as expected, but won't often today. So, who's telling a lie?

A couple of years ago, not sure, but there certainly were some hot topics about disk write back cache.

Linux: Should disk write cache be disabled for any journalised filesystem?

Windows: Manually Enable/Disable Disk Write Caching

In the Windows manual, the latter one, you'll see a clear description.

By enabling write caching, file system corruption and/or data loss could occur if the machine experiences a power, device or system failure and cannot be shutdown properly.

So, it is natural to disable the write cache by default, from the database vendor's point of view.

But today, disk write back cache is enabled by default. Often, you can not even get a way to disable it. This is for the sake of performance because of the Coelacanth, HDD, in computer.

What makes it worth is an emergence of some kind of virtualization like Java and .NET.

sync
public void sync() throws SyncFailedExceptionForce

all system buffers to synchronize with the underlying device. This method returns after all modified data and attributes of this FileDescriptor have been written to the relevant device(s). In particular, if this FileDescriptor refers to a physical storage medium, such as a file in a file system, sync will not return until all in-memory modified copies of buffers associated with this FileDesecriptor have been written to the physical medium. sync is meant to be used by code that requires physical storage (such as a file) to be in a known state For example, a class that provided a simple transaction facility might use sync to ensure that all changes to a file caused by a given transaction were recorded on a storage medium. sync only affects buffers downstream of this FileDescriptor. If any in-memory buffering is being done by the application (for example, by a BufferedOutputStream object), those buffers must be flushed into the FileDescriptor (for example, by invoking OutputStream.flush) before that data will be affected by sync.

Throws:
SyncFailedException - Thrown when the buffers cannot be flushed, or because the system cannot guarantee that all the buffers have been synchronized with physical media.
Since:
JDK1.1

.NET: FileStream.Flush not flushing?

FileStream.Flush Method
Clears all buffers for this stream and causes any buffered data to be written to the file system.

Stream.Flush Method
When overridden in a derived class, clears all buffers for this stream and causes any buffered data to be written to the underlying device.

Microsoft Windows CE .NET 4.2
FlushFileBuffers
This function clears the buffers for the specified file and causes all buffered data to be written to the file.

Copy CodeBOOL WINAPI FlushFileBuffers(
HANDLE hFile
); Parameters
hFile
[in] Handle to an open file. The function flushes this file's buffers. The file handle must have GENERIC_WRITE access to the file.
If hFile is a handle to a communications device, the function only flushes the transmit buffer.

Return Values
Nonzero indicates success. Zero indicates failure. To get extended error information, call GetLastError.

Remarks
The WriteFile function typically writes data to an internal buffer that the OS writes to disk on a regular basis. The FlushFileBuffers function writes the buffered information for the specified file to disk.

Requirements
OS Versions: Windows CE 1.0 and later.
Header: Winbase.h.
Link Library: Coredll.lib.

Then, unless you are aware of hardware and its underlying architectures, innocent Java/.NET guys would be misled.

I will check some major langurages/OSes how they describe its sync behavior, and then ask to fix or put a warning if necessary.

The next question is what is the best workaround for you. I will write it in my next column.