Re: vfs_journal.c code questions

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:...
:jrecord_init(jo, &jrec, JREC_STREAMID_DISCONT);
:jrecord_write(&jrec, JTYPE_ASSOCIATE, 0);
:...
:
:
:1) the `streamid' parameter for jrecord_init() is set to
:   JREC_STREAMID_DISCONT which is defined as 0x0002.
:
:   While in function jrecord_init():
:
:    ...
:    if (streamid < 0) {
:        streamid = sid++;       /* XXX need to track stream ids! */
:        if (sid == JREC_STREAMID_JMAX)
:            sid = JREC_STREAMID_JMIN;
:    }
:    jrec->streamid = streamid;
:    ...
:
:    So now jrec->streamid is JREC_STREAMID_DISCONT (0x0002).
:
:    Shouldn't streamid be some number between JREC_STREAMID_JMIN and
:    JREC_STREAMID_JMAX?
:
:#define JREC_STREAMID_JMIN      0x0100  /* lowest allowed general id */
:#define JREC_STREAMID_JMAX      0x2000  /* (one past the highest allowed id) */
:...
:Thanks,
:
:Rongsheng

    It's a work in progress! :-)  Basically the idea with the 0x0100-0x2000
    was that those stream ID's would represent transactions that potentially
    run in parallel, whos contents are in the subrecord format.   These 
    ID's would be short-lived and 'reusable' meaning that the ID's have no
    special meaning and could be reusable after the transaction completes.

    Id's below 0x0100 contain out of band data that is not necessarily
    in the subrecord format and not necessarily bound by the transaction 
    rules used by the main ID set.  So, e.g. system time stamps, a heartbeat
    record, text annotations issued by the system operator via mountctl, and
    other things.

    This might not be the best way to organize the structure... the subrecord
    data format is nicely abstracted and I might wind up using it inside all
    the stream records.  I haven't decided yet.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>