> > > 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 where
tests 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're > running 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. > Linux CentOS x86_64. A lot of memory, 8 processors. 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.
