That's not quite the way I remember it. If the file doesn't
fit in one block, then the first block contains a list of
pointers to the blocks that make up the file, if all the
pointers fit in one block. If they don't fit in one block,
then the first block contains a list of pointers that
contain another list of pointers to the file blocks. Also,
I seem to recall that the FST for a recfm V file contains
the first and last record number of the file, thus
improving random access.
What you describe sounds like the old 800 byte block
variable record format.
Like yourself however, this is without reference to any
manuals!
Les
Mike Walter wrote:
PS,
As Sue Farrell related in a previous post, if you have the PTF for APAR
VM64513 applied you may not be subject to that lengthy delay as we are
with one system still running z/VM 5.1
But to answer the question as best I can from memory. DISCLAIMER: I'm not
in the office today, so the exact details may be "slightly off" - just
like me. The general method should be pretty close, experts can correct
the details if it's too far off.
ECDK files have an entry in the File Status Table which resides on that
MDISK. The FST, along with other information contained therein, points to
the first block of each file. Each file block is chained by a pointer to
the next block. Erasing the file just turns off the pointer in the FST to
the first file block (similar to Windows' FAT filesystem). There's more
to the ECKD filesystem than that, but the main point here is the speed of
clearing a single pointer inside the already-in-storage FST.
In SFS, the SFS server manages a catalog mdisk. That catalog has a
pointer to every 4K block in the filepool. When a (large or small) is
erases, the block pointer for every file needs to be cleared, and IIRC, a
bit in every block that the made up the block. Without looking at the
PTF, perhaps something in that process was updated to speed things up,
just guessing.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"P S" <zosw...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
12/22/2009 01:49 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Larger CMS Disk
On Tue, Dec 22, 2009 at 2:45 PM, Mike Walter <mike.wal...@hewitt.com>
wrote:
The problem with bigger on SFS is that it is on SFS.
Try writing, say, a big honking (historically for CMS, but NOTHING to
Linux) 12G file into SFS. No problem - writes are a little slower than to
a minidisk, but not enough to complain about (unless, perhaps, many others
are trying to do the same thing using the same SFS server!).
But when you erase that 12G file, SFS takes almost "forever". Unlike an
ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS
has to go though each of the 4K blocks that constitute the file, turning
off its allocation bit. For a large file that can take 15+ minutes (in
the case of one 12G file we were working with). And CPU utilization due
to the server pretty much peaks out during that time, too. The exact
details may be slightly off in that example, but the observable effect is
pretty accurate.
Even one of the original SFS authors, Scott Nettleship, said repeatedly of
SFS: "If you want minidisk performance, use minidisks".
Not understanding something: writing the file has to write each of the 4K
blocks too. Are you saying that the ERASE is slower than the WRITE? Or
just that while it feels reasonable for the original WRITE to take a
while, the fact that the ERASE is so slow is anomalous?
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
