XFC cachinh of no_caching file ?

[DICTU OpenVMS]

For backup pupose we nightly make an entire export of our Oracle 8i database. The export doesn't need te be read again (until...). So we've set the directory attributes of the export dir to no_caching. But when I look at the xfc stat's it seems that the file is still in the cache. VMS 7.3-1 with recent patches. Output (somewhat edited) :

$ sh mem /cache=(vol=disk$expdisk)
System Memory Resources on 9-DEC-2003 09:04:13.24

Extended File Cache Volume Statistics:

_$1$DGA714: (DISK$EXPDISK), Caching mode is VIOC Compatible
Open files 0
Closed files 1
Files ever opened 200
Files ever deposed 199
Allocated pages 158225
Locks acquired 0
Total QIOs 102128
Read hits 0
Virtual reads 0
Virtual writes 102128
Hit rate 0 %
Read aheads 0
Read throughs 0
Write throughs 102128
Read arounds 0
Write arounds 0
Ave Disk I/O Resp Time incl cache hits (microseconds) 658

Total of 1 volume in cache


$ sh mem /cache=(file=disk$expdisk:*.*) /ful
System Memory Resources on 9-DEC-2003 09:04:19.41

Extended File Cache File Statistics:

_$1$DGA714:[EXPORTS]ENTIRE_REP.EXP;1 (closed)
Caching is enabled, active caching mode is No Caching
Allocated pages 158225
Total QIOs 102128
Read hits 0
Virtual reads 0
Virtual writes 102128
Hit rate 0 %
Read aheads 0
Read throughs 0
Write throughs 102128
Read arounds 0
Write arounds 0

Total of 1 file for this volume


$ dir $1$DGA714:[EXPORTS]ENTIRE_REP.EXP /cach

Directory $1$DGA714:[EXPORTS]

ENTIRE_REP.EXP;1 No_caching

Total of 1 file.

[Willem Grooters]

RMS will use caching for performance sake (and because it's technically required: Disk IS slow!).
What you see here is in fact just IO statistics, I don't think there will be any data left. That means that read will turn toi disk (and place data in this buffer and update statistics).
XFC does quite a lot of things, apart from caching (meaning "shared access" where data is kept available).

[DICTU OpenVMS]

But if the show output is just IO stat's, why do I get about 1 GB of memory back from the XFC cache if I dismount/mount the disk ?

[Willem Grooters]

RMS will use XFC as buffer - for read/write operations, directory maintenance etc. So there WILL be (virtual) memory allocated even if you specify "no_cache". As stated before, it means "Any read should come from disk" so XFC is used as buffer only. Not as a cache in the current sense (meaning: shared data, it's in memory so don't go to disk).

(OFF TOPIC: he collega! ;-)

[Hein van den Heuvel]

(Als jullie twee morgen vroeg allebei om 10:00 naar de koffie machine lopen, dan kun je het mooi in persoon doorpraten :-)
Ik weet het ook niet,
Groetjes,
Hein.

[Mark Hopkins_4]

XFC does not have any mechanism to force a
particular file out of memory. When you set the file to no_caching, this will cause future I/Os to this file to bypass the cache. Memory allocated to the file will
be recycled using the normal LRU mechanism
in the cache.

When a volume is dismounted, then all the XFC memory for files on that volume is freed - so you'll see the memory show up
immediately. For the next version of XFC,
the depose code (i.e. the code that throws
stuff out of cache) was speed up by a large
factor (up to 20x for some systems). One side effect of this change will be that the depose due to the dismount will not appear
to have released the memory. However, it
is available and is the first used when
memory is required.

Mark Hopkins

[DICTU OpenVMS]

Mark,

Thank you. But I still don't understand it right. The export file is deleted the day after, and then a new export is created. I set the directory to no_caching, so the newly created file is also set to no_caching. So in my humble opinion the newly created file shouldn't go into the cache (allocated pages should be 0). I want the file to be write_around, not write_through. The file is just for emergancy use...

[DICTU OpenVMS]

OFF TOPIC : Hein : Helaas zitten wij niet bij dezelfde opdrachtgever... ;-)

[Willem Grooters]

Setting the directory itself to NO_CAHING could not be sufficient. You need to set the files under it to NO_CAHING as well. I found this in the system manager's manual for 7.3-2:

This example sets the caching attribute to no caching for all the files in and under the directory [SMITH.BORING].

The first SET FILE command sets the attribute for the directory to make sure that all files and subdirectories subsequently created in it inherit the attribute. The second SET FILE command sets the attribute for all existing files and directories in and under the directory.
$ SET FILE DISK$USERS:[SMITH]BORING.DIR;1 /CACHING_ATTRIBUTE=NO_CACHING
$ SET FILE DISK$USERS:[SMITH.BORING...]*.*;* /CACHING_ATTRIBUTE=NO_CACHING

I think this holds for older versions as well.
Just check the attribute is set:

This example uses the DIRECTORY command's /CACHING_ATTRIBUTE qualifier to show the caching attribute of MYFILE.TXT:
$ DIRECTORY MYFILE.TXT /CACHING_ATTRIBUTE

Directory DISK$USERS:[SMITH]
MYFILE.TXT;1 Write-through
Total of 1 file.

(well, this on eis write_through, not no_cache but you'll understand the meaning).

If you make your exports to a separate disk, consider mounting the disk /NOCACHE:

This example mounts a database volume labeled ORACLE_VOL1 with caching disabled:

$ MOUNT DUA100: ORACLE_VOL1 /NOCACHE /SYSTEM

[Willem Grooters]

(OFF TOPIC: hein: kweetnie eens wie kweetnie is. Erg he? Maar hij weet me vast wel te vinden ;))

[Mark Hopkins_4 · Accepted solution]

Opps - you're right.

This problem was fixed after V7.3-1 shipped.
The original design had i/os marked nocache
allocating space in the cache (there were
good reasons for this at the time) and not
releasing the space when the I/O was complete. There were several things that
were done to fix this -
1) Write I/Os marked nocache (either because of the volume state, file state,
I/O size or directly marked) will bypass the
cache very early in the processing. (This
was already true for read I/Os).
2) At the completion of the I/O, if a
page doesn't contain valid data, the page is
released.

Sorry for the confusion. A kit for V7.3-2
containing this fix and other performance
enhancements should be available by tomorrow
morning Eastern Standard Time. This kit will
named VMS731_XFC-V0200.PCSI and replaces
the V0100 kit. The kit for V7.3 has been
available for about a week. I recommend
applying these kits. Note that these
include all the changes and enhancements made
to XFC for V7.3-2.

A work around in the meantime is to mount
the volume /nocache. For V7.3-1, this case
was treated correctly for write i/os.
Unfortunately, this has the nasty effect of
turning off the file system caches (i.e.
XQP).

The problem isn't quite as bad as it
appears. It turns out that the blocks added
to this file will be in the low end of the
LRU queue and so will be deposed prior to
valid blocks.

You're procedure for setting the file
attributes is correct. Setting the nocache
bit on the directory will cause new files
to inherit this attribute. It will not
affect existing files.

Sorry for the confusion,

Mark Hopkins

[DICTU OpenVMS]

Mark,

Thanks for your reply. We applied the patch yesterday (along with update 2, sys 5, acrtl 3, graphics 2 and partitioning 2). But it doens't seem to have solved the "problem". There are still a lot of pages allocated to the export file, which is marked no_cache...

I know that the file will be pushed out of the cache, when needed, but I actually don't wan't it to get into the cache in the first place... ;-) Mounting /nocache is a bad option, because the disk also contains files that take advantage of the cache...

The output :

$ sh mem /cach=(file=DISK$EXPDISK:*.*)
System Memory Resources on 8-JAN-2004 08:22:53.91

Extended File Cache File Statistics:

_$1$DGA714:[EXPORTS]ENTIRE_REP.EXP;1 (closed)
Caching is enabled, active caching mode is No Caching
Allocated pages 183141 Total QIOs 94329
Read hits 0 Virtual reads 0
Virtual writes 94329 Hit rate 0 %
Read aheads 0 Read throughs 0
Write throughs 94329 Read arounds 0
Write arounds 0

Total of 1 file for this volume

$ dir $1$DGA714:[EXPORTS] /cache

Directory $1$DGA714:[EXPORTS]

ENTIRE_REP.EXP;1 No_caching

Total of 1 file.


$ prod show hist /since=yes
----------------------------------- ----------- ----------- --------------------
PRODUCT KIT TYPE OPERATION DATE AND TIME
----------------------------------- ----------- ----------- --------------------
DEC AXPVMS VMS731_GRAPHICS V3.0 Patch Install 07-JAN-2004 18:59:51
DEC AXPVMS VMS731_XFC V2.0 Patch Install 07-JAN-2004 18:59:09
DEC AXPVMS VMS731_SYS V5.0 Patch Install 07-JAN-2004 18:58:38
DEC AXPVMS VMS731_PARTITIONING V2.0 Patch Install 07-JAN-2004 18:57:54
DEC AXPVMS VMS731_ACRTL V3.0 Patch Install 07-JAN-2004 18:57:21
DEC AXPVMS VMS731_UPDATE V2.0 Patch Install 07-JAN-2004 18:53:48
----------------------------------- ----------- ----------- --------------------

6 items found

[Mark Hopkins_4]

O my...

I've reproduced this here. I'll let you
know when I have more information.

Thanks for reporting this.

Mark

[Mark Hopkins_4]

I believe that I've identied the bug (not
in XFC). It was introduced in V7.3-1. I'm
not going to give any details in case I'm
wrong (2 wrong answers in one thread is
sending me home pretty humble).

If this is a sequential file, the following
will flush the pages for the file from
the cache. I think that the bug applies
to either non-shared, sequential files or
files open with deferred write enabled
(DFW).

$ open/read/share x x.x
$ close x

Let me know if this doesn't work. I'll look
for something better, but nothing comes to
mind.

I'll log a report, but it might help to
log a customer report as well.

Thanks for your patience and persistence.

Mark Hopkins

[Wim Van den Wyngaert]

I have 7.3 and have the same problem.
It's not solved by open+close.

But if I use the file it clearly isn't cached any more because hit rate decreases.

Wim