Denys Beauchemin wrote:

> You still do not understand.
>
> You confuse the XM checkpoint process, which is done at the volumeset
> level, with the posting to the master of the volumesets as I explained
> it.  You also insist that all of main memory gets scanned at checkpoint
> time.  I say it does not.

You have to look at this from a non-theoretical angle:

1) Yes, true, XM does not 'scan' ALL of the pages in memory.

2) No, false, XM may need to 'scan' ALMOST ALL pages in memory.

Assume you have 8GB of physical memory and 95% of the
available physical pages are in use by 3 or 4 Image datasets
that all your users are constantly touching and changing.
I.e. you most frequently used (and updated) files will have
a typically high 'locality' percentage in memory.

Then 95% of all memory is in use by pages belonging to
XM attached user files. And if these files have XM transactions
when the checkpoint occurs, the OS needs to 'scan' the system
to find the dirty pages.

It was in 6.0, when HP introduced a bitmap that helped avoiding
that scanning (ALTERCHKPOINTSTAT in VOLUTIL), but the data structure
used was only good for <= 4GB files, and HP had to turn this
enhancement off in 6.5 for large file support.


3) You are right when you describe the contents of the XM logs
as being journal transactions (with before and after image
records).

However you are wrong to think that XM applies the changes
per what is in these before and after image records during
checkpoints, these logrecords only get used (record by record)
in the recovery (system crash) case.

During checkpoint time, XM just checks which files that are
attched had transactions, and will get the dirty pages from
these files posted.

You will actually have many cases where the same dirty
memory page will correlate to multiple XM logrecords
(aka transactions) and XM will save on disk IOs, because
instead of serially applying the (logical) before/after
image transactions (might be e.g. 20 DBUPDATEs hitting the
same 4k page) it just posts one dirty page.
So this saves on IOs (usually) rather than causing more
unnecessary ones.


Not sure if this helps, but I hope so.

Goetz.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *