CMS' EDF file system also has an allocation map (in fact, it is one of 2 hidden CMS files). The freed blocks must be reflected there as well. A bit more work than just "turning off the first pointer".
Internally SFS though has much in derived from SQL/DS (now DB2/VM), it can manage much more space than a single minidisk, and sometimes one pays a price a bit too high for this. Glad to read this issue is solved. 2009/12/23 Mike Walter <mike.wal...@hewitt.com> > > 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*<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. -- Kris Buelens, IBM Belgium, VM customer support
