Also, the controller is configured to use 75% of its memory for write caching and 25% - for read caching. So reads cannot flood writes.
On 8/23/07, Dmitry Koterov <[EMAIL PROTECTED]> wrote: > > > 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. > > >
