Kevin Brown <kevin@sysexperts.com> writes:
> Even that's not strictly necessary -- we *do* have shared memory we
> can use for this, and even when hundreds of tables have been written
> the list will only end up being a few tens of kilobytes in size (plus
> whatever overhead is required to track and manipulate the entries).
Why not just fsync _all_ the database table files? If there's no I/O pending
on them then the fsync might be very quick. I guess that's something to test,
how fast is fsyncing a few hundred file descriptors that have no pending
changes. Hell, if you keep all the file descriptors open (yes I know some
systems have problems with that) you don't even need to open and close them,
just loop calling fsync umpteen times.
> > Of course, if there are lots of files, sync() may be faster than
> > opening/fsync/closing all those files.
>
> This is true, and is something I hadn't actually thought of. So it
> sounds like some testing would be in order.
Note that the average case here isn't nearly as important as the worst-case.
It would really suck to find out that running some other program (say a backup
restore on another partition?) suddenly kills your database response because
that sync suddenly has gigabytes of data to sync.
Actually the real problem with sync is that it's, er, asynchronous. The kernel
will return before the data is actually synced. Waiting an arbitrary amount of
time might work in the average case but when something else fills the kernel
buffers with pending i/o that arbitrary time might prove to be inadequate and
it could open a window where a crash could corrupt the database integrity.
> Unfortunately I know of no system call which will take an array of
> file descriptors (or file names! May as well go for the gold when
> wishing for something :-) and sync them all to disk in the most
> optimal way...
mmmmm, yum.
--
greg
