On 8/23/07, Dmitry Koterov
<dmitry@xxxxxxxxxx> wrote:
Linux CentOS x86_64. A lot of memory, 8 processors.> I have written a small perl script to check how slow is fsync for Smart
> Array E200i controller. Theoretically, because of write cache, fsync MUST
> cost nothing, but in practice it is not true
That theory is fundamentally flawed; you don't know what else is in the
operating system write cache in front of what you're trying to fsync, and
you also don't know exactly what's in the controller's cache when you
start. For all you know, the controller might be filled with cached reads
and refuse to kick all of them out. This is a complicated area wheretests are much more useful than trying to predict the behavior.
Nobody else writes, nobody reads. The machine is for tests, it is clean. I monitor dstat - for 5 minutes before there is no disc activity. So I suppose that the conntroller cache is already flushed before I am running the test.
tests are much more useful than trying to predict the behavior. You haven't mentioned any details yet about the operating system you'rerunning on; Solaris? Guessing from the device name. There have been some
comments passing by lately about the write caching behavior not being
turned on by default in that operating system.
Filesystem is ext2 (to reduce the journalling side-effects).
OS write caching is turned on, turned off and also set to flush once per second (all these cases are tested, all these have no effect).
The question is - MUST my test script report about a zero fsync time or not, if the controler has built-in and large write cache. If yes, something wrong with controller or drivers (how to diagnose?). If no, why?
There are a lot of discussions in this maillist about fsync & battery-armed controller, people say that a controller with builtin cache memory reduces the price of fsync to zero. I just want to achieve this.
