Query re volume extent cache - VMS

This is a discussion on Query re volume extent cache - VMS ; Gentle colleagues (this is also posted on EISNER in the Notes forum): I'd appreciate your thoughts on this: The goal for a particular disk volume is to have any file extend operations as fast as possible. Tests show that file ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Query re volume extent cache

  1. Query re volume extent cache

    Gentle colleagues (this is also posted on EISNER in the Notes forum):

    I'd appreciate your thoughts on this:

    The goal for a particular disk volume is to have any file extend operations
    as fast as possible.

    Tests show that file extends which can be satisfied from VMS's volume extent
    cache complete in about 0.01 seconds. When the system has to go back to the
    BITMAP.SYS (i.e. not enough blocks in the extent cache to satisfy the request)
    the time for the extend to complete goes up to a pretty consistent 0.33
    seconds (all this is on a standalone ES40 with local disks).

    Note: all of this is with highwater marking DISABLED, and no requests are
    for contiguous or contiguous-best-try.

    So, I thought the obvious thing to do was to make sure this volume gets
    mounted with:

    $ mount/system dka0:/cache=(LIMIT=1000,EXTENT=2048) Data

    As in:

    $ help mount /cache

    MOUNT

    /CACHE

    /CACHE=(keyword[,...])
    /NOCACHE

    For disks, controls whether caching limits established at system
    generation time are disabled or overridden.

    The following table lists the keywords for this qualifier:

    Keyword Description

    EXTENT[=n] Enable or disable extent caching. To enable extent
    and NOEXTENT caching, you must have the operator user privilege
    (OPER) and you must specify n, the number of
    entries in the extent cache. Note that NOEXTENT
    is equivalent to EXTENT=0; both disable extent
    caching.

    [...snip...]

    LIMIT=n Specifies the maximum amount of free space in the
    extent cache in one-thousandths of the currently
    available free space on the disk.

    However, I'm seeing behaviour that I cannot explain.

    OK, let's mount the volume (and just to make sure we don't get anything
    else involved, we'll also specify /Proc=Unique).

    $ mou/sys/cac=(limi=1000,ext=2048) dka0 data/proc=uniq
    DATA mounted on DKA0:
    $ sh dev dka0/full
    [...stuff snipped...]
    Free blocks 643698 Maximum files allowed 419004
    Extend quantity 2048 Mount count 1
    Mount status System Cache name "_P4$DKA0:XQPCACHE"
    Extent cache size 2048 Maximum blocks in extent cache 643698
    File ID cache size 64 Blocks in extent cache 0


    Looking at the volume with DFU - we see that the number of free extents is 90:

    ***** Free space statistics (from BITMAP.SYS) *****
    Total blocks on disk : 8380080
    Total free blocks : 643698
    Percentage free (rounded) : 7
    Total free extents : 90 <----
    Largest free extent : 64287 blocks at LBN: 6334425
    Average extent size (rounded) : 7152
    Free space fragmentation index : 0.014 (excellent)

    Next let's create a file so that VMS will populate the extent cache.

    $ copy/log/alloc=64288 nl: x.x
    NL: copied to DISK$DATA:[ROYO]X.X;6 (0 records)

    $ dire x.x.
    Directory DISK$DATA:[ROYO]
    X.X;6 0/64296

    Now, let's Show Dev/Full again:

    [...snipped...]
    Free blocks 579402 Maximum files allowed 419004
    Extend quantity 2048 Mount count 1
    Mount status System Cache name "_P4$DKA0:XQPCACHE"
    Extent cache size 2048 Maximum blocks in extent cache 579402
    File ID cache size 64 Blocks in extent cache 8271

    Question: What caused the number of "Blocks in extent cache" to go to 8,271
    (I was really hoping it would be all of the free extents, in other words,
    it should be 579,402.

    Next, let's really exhaust everything by creating a file to mop up all
    free blocks:

    $ delete x.x.
    $ copy/log/alloc=643698 nl: x.x
    NL: copied to DISK$DATA:[ROYO]X.X;6 (0 records)
    $ show dev dka0/full
    [...snipped...]
    Free blocks 0 Maximum files allowed 419004
    Extend quantity 2048 Mount count 1
    Mount status System Cache name "_P4$DKA0:XQPCACHE"
    Extent cache size 2048 Maximum blocks in extent cache 0
    File ID cache size 64 Blocks in extent cache 0

    Again, with DFU, we can see that the file has 90 fragments, as was entirely
    expected:

    P4$DKA0:[ROYO]X.X;6 0/643698 2/90

    Now, when we delete this file, I think it's reasonable to expect all 90
    freed extents to end up in the extent cache ...

    $ delele/log x.x.
    DISK$DATA:[ROYO]X.X;6 deleted (643698 blocks)
    $ show dev dka0/fu
    [...]
    Free blocks 643698 Maximum files allowed 419004
    Extend quantity 2048 Mount count 1
    Mount status System Cache name "_P4$DKA0:XQPCACHE"
    Extent cache size 2048 Maximum blocks in extent cache 643698
    File ID cache size 64 Blocks in extent cache 49950

    But, no ... only 49,950 free blocks' worth of extents are in the cache.

    Why not all 643,698 (in 90 extents) ???

    I can drill down through the UCB -> VCB -> VCA -> VCA$L_EXTCACHE 816C7AC8
    to the extent cache, which looks like this:

    SDA> ex 816C7AC8;200
    000003E8 0000C31E 00000009 00000800 .........C..h... FFFFFFFF.816C7AC8
    20000000 00000000 00000000 00000000 ............... FFFFFFFF.816C7AD8
    00000000 00000000 00000000 00000000 ................ FFFFFFFF.816C7AE8
    004C77A2 0000066F 00000000 00000000 ........o..."wL. FFFFFFFF.816C7AF8
    004F400A 00000051 004EA902 0000137A z....)N.Q....@O. FFFFFFFF.816C7B08
    0056A681 0000211E 004F40B5 000007B3 3...5@O..!...&V. FFFFFFFF.816C7B18
    005A649E 00000630 00596508 0000298E .)...eY.0....dZ. FFFFFFFF.816C7B28
    00620595 000026B5 0061DBEC 000029A0 .)..l[a.5&....b. FFFFFFFF.816C7B38
    00565CC8 00001A55 0057FD98 0000042F /....}W.U...H\V. FFFFFFFF.816C7B48
    00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B58
    00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B68
    00565CC8 00001A55 00565CC8 00001A55 U...H\V.U...H\V. FFFFFFFF.816C7B78
    00418BCC 000015BA 00565CC8 00001A55 U...H\V.:...L.A. FFFFFFFF.816C7B88
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7B98
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BA8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BB8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BC8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BD8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BE8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7BF8
    00418BCC 000015BA 00418BCC 000015BA :...L.A.:...L.A. FFFFFFFF.816C7C08

    Some of these clearly correspond to LBN/number-of-free-blocks pairs, and
    which I could see in the X.X file before its deletion.

    Any comments/thoughts ? Anything I'm overlooking in my attempt to get
    all free extents to be mapped in the extent cache ?

    Thanks, Roy.

  2. Re: Query re volume extent cache

    On Nov 22, 10:41 am, om...@encompasserve.org (R.A.Omond) wrote:
    > Gentle colleagues (this is also posted on EISNER in the Notes forum):

    :
    > The goal for a particular disk volume is to have any file extend operations
    > as fast as possible.


    Thats a fine start, but curious minds want to know why this is
    critical to you.
    Just the GP (General Principle) or, is there a specific, application
    defined, need to meet? Maybe there are better ways to tackle those
    application needs?
    Pre-extends? Large default extentds? SET RMS/EXTE=64000 ?


    > $ mou/sys/cac=(limi=1000,ext=2048) dka0 data/proc=uniq
    > $ sh dev dka0/full
    > File ID cache size 64 Blocks in extent cache 0
    >
    > Looking at the volume with DFU - we see that the number of free extents is 90:

    :
    > Largest free extent : 64287 blocks at LBN: 6334425


    > Next let's create a file so that VMS will populate the extent cache.
    >
    > $ copy/log/alloc=64288 nl: x.x

    :
    > Now, let's Show Dev/Full again:
    >
    > [...snipped...]
    > Extent cache size 2048 Maximum blocks in extent cache 579402
    > File ID cache size 64 Blocks in extent cache 8271
    >
    > Question: What caused the number of "Blocks in extent cache" to go to 8,271
    > (I was really hoping it would be all of the free extents, in other words,
    > it should be 579,402.


    Stuff gets into the extend cache by truncating (which is integral to
    delete), not by scanning for space.

    You did not specify /CONT on the copy, so I do not think that file
    got the large contiguous extend. I think it just started collecting
    free space and the 8271 is a leftover from the last free chunk it
    used.


    > Next, let's really exhaust everything by creating a file to mop up all free blocks:

    :
    > $ delele/log x.x.
    > DISK$DATA:[ROYO]X.X;6 deleted (643698 blocks)
    > $ show dev dka0/fu
    > [...]
    > Free blocks 643698 Maximum files allowed 419004
    > Extend quantity 2048 Mount count 1
    > Mount status System Cache name "_P4$DKA0:XQPCACHE"
    > Extent cache size 2048 Maximum blocks in extent cache 643698
    > File ID cache size 64 Blocks in extent cache 49950
    >
    > But, no ... only 49,950 free blocks' worth of extents are in the cache.
    >
    > Why not all 643,698 (in 90 extents) ???


    I did not drill down all the way, but there is a percetage of free
    space involved:

    From F11X\V732\SMALOC

    ROUTINE MAX_CACHE_SPACE
    :
    ! This routine computes the maximum free space that may be
    ! reserved in one extent cache. We limit the amount of space in
    ! the cache two ways:
    ! (1) by absolute percentage with cache fill limit
    ! (2) by dividing free space by mount count plus 2.
    ! The latter prevents overcommittment of the extent cache in
    ! large clusters, which can lead do dismal thrashing situations.

    Hope this helps some,
    Hein van den Heuvel
    HvdH Performance Consulting.


+ Reply to Thread