Thread: Re: SRA Win32 sync() code

Re: SRA Win32 sync() code

From
"Merlin Moncure"
Date:
Bruce Momjian wrote:
> Here is the SRA sync() code for Win32.  As you might know, fsync on
> Win32 is _commit, and sync() is _flushall.  However, _flushall only
> flushes only _open_ kernel buffers, not dirty buffers that have been
> closed.  Therefore, on Win32, during checkpoint, you have to open,
> fsync(_commit), close all file that have been modified since the
> previous checkpoint.

That is not quite correct.  flushall() flushes all open file streams,
not open file 'handles' i.e. array references to _osfile[] returned by
_open().  flushall() is an aggregate fflush() command().  Note that this
is as implemented by Microsoft C runtime, not necessarily MinGW.  So,
when compiled with the ms C libraries, _flushall is useless.

A _handle based flushall routine would have to loop over the _osfile
array and commit file handles, or track them externally as SRA did.

What about rewriting the close routine to call FlushFileBuffers before
closing the file?  Would this break anything?

> Not sure how we are going to do this in Win32, but somehow we will
have
> to record all open files between checkpoints in an area that the
> checkpoint process can read during a checkpoint.

Iff the file handles can be reliably commited on closure this would not
be necessary.  The C runtime already keeps track of open files.

Merlin


Re: SRA Win32 sync() code

From
Bruce Momjian
Date:
Merlin Moncure wrote:
> Bruce Momjian wrote:
> > Here is the SRA sync() code for Win32.  As you might know, fsync on
> > Win32 is _commit, and sync() is _flushall.  However, _flushall only
> > flushes only _open_ kernel buffers, not dirty buffers that have been
> > closed.  Therefore, on Win32, during checkpoint, you have to open,
> > fsync(_commit), close all file that have been modified since the
> > previous checkpoint.
>
> That is not quite correct.  flushall() flushes all open file streams,
> not open file 'handles' i.e. array references to _osfile[] returned by
> _open().  flushall() is an aggregate fflush() command().  Note that this
> is as implemented by Microsoft C runtime, not necessarily MinGW.  So,
> when compiled with the ms C libraries, _flushall is useless.
>
> A _handle based flushall routine would have to loop over the _osfile
> array and commit file handles, or track them externally as SRA did.
>
> What about rewriting the close routine to call FlushFileBuffers before
> closing the file?  Would this break anything?
>
> > Not sure how we are going to do this in Win32, but somehow we will
> have
> > to record all open files between checkpoints in an area that the
> > checkpoint process can read during a checkpoint.
>
> Iff the file handles can be reliably commited on closure this would not
> be necessary.  The C runtime already keeps track of open files.

The problem is that fsync on commit of all open files would cause poor
performance.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073