On 11/16/05, Mladen Jovanovski wrote:
>
> On 11/16/2005 07:36 AM, Jonathan Leffler wrote:
> > On 31 Oct 2005 16:32:18 -0800, david@smooth1.co.uk wrote:
> >>
> >> Well I've looked at IDS 10.00.TC3R1Tl release notes and
> >>
> >> Section 1.3.7
> >>
> >> Buffer should avoid bf_check calls (??).
> >> What is this? An internal consistency check?
> >> Why avoid it?
> >>
> >> Buffer has been 'buff'-checked??
> >> What is that?
> >
> > Where did you get a version 10.00.TC3R1T1 from?
> >
> > I didn't know you could get 7 characters after the second full stop
> > (period).
> >
> > I asked a colleague if he knew anything about such a version - and he
> was
> > equally mystified.
> > And he didn't think that the message existed in current versions of IDS,
> > unless I misread his message.
>
> Jonathan, the latest trial version of IDS from
>
>
http://www-128.ibm.com/developerwork...105AGX28&S_CMP
=DLMAIN
> have this strange numbering scheme.



Thank you, Mladen and Carsten - I didn't spot the one pixel difference
between a lower-case L and a digit 1; oops.


In my case, for Linux:
>
> > cat etc/IIF-cr
> > IBM Informix Dynamic Server Version 10.00.UC3R1TL
> > Copyright (C) 1986-2005 IBM Corporation, All rights reserved
>
> File release/en_us/0333/ids_adref_docnotes_10.0.txt titled as
>
> <quote>
> IBM Informix
> Documentation Notes for the IBM Informix Dynamic Server Administrator's
> Reference
>
> 10.00.xC3 1 July 2005
> </quote>
>
> have the following section:
>
> <quote>
> 1.3.7 Buffer Page Status Flags of onstat -X Command
>
> The documentation of the onstat -X command in Chapter 3 describes only
> the first four bits of the flags bitmap. The following description of
> the flags parameter of onstat -X is more complete:
>
> flags Flags identifying the current status of the buffer page:
>
> 0x01 Modified Dat
> 0x02 Data
> 0x04 LRU
> 0x08 Error
> 0x20 LRU AIO write in progress
> 0x40 Chunk write in progress
> 0x80 Buffer is/will be result of read-ahead
> 0x100 Cleaner assigned to LRU
> 0x200 Buffer should avoid bf_check calls
> 0x400 Do log flush before writing page
> 0x800 Buffer has been 'buff' -checked
> 0x8000 Buffer has been pinned
> 0x10000 Buffer modified by fuzzy operation.
> </quote>
>

Thanks.

You'll probably find that the 'buff checked' status means that the page was
read from disk into the buffer pool and the page header bytes were
validated. The value on disk should have the bit unset, so IDS can tell
whether the page has been processed since the KAIO or AIO VP transferrred
the page into memory.

As to why to avoid bf_check() calls - they take some time; not a huge amount
in processing terms, but the bf_check() code usually has one of the highest
latencies simply because it is the first function to hit a page, so the o/s
paging system has to read the page into memory, and that incurs overhead.
Some function has to be the first to read from a page, and whatever function
that is will incur the penalty.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
sending to informix-list