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.
