Re: Fw: Linux CDL packs on RVA
Let me tell something about the background. Long time ago we decided to set DS1LSTAR to zero, because it is to small for larger partitions. The TTR field allowes us partition sizes of max 3GB for a usual Linux ECKD geometry (12 blocks per track and 4k block size). We did not want this restriction. The alternative, using the extended format (DS1LSTAR and DS1TRBAL), did also not work. Sure, then we had a R field to flag the partitions as used, which is large enough. But to use DS1TRBAL, the data on the ECKD DASD have to be in a certain format, e.g. a 32 byte prefix for each block and others. And in addition, z/OS would expect other than Linux data behind this format and we have again a problem. The compromise was to set DS1LSTAR to zero, to indicate here is something different and to document this. regards, Volker
Re: Fw: Linux CDL packs on RVA
Interval DDSR never looks inside the boundaries of a dataset. Setting DS1LSTAR would prevent DFHSM space management or a user from issuing a 'Free' request to release unused data within the boundaries of one of the datasets that represent partitions, which would be a good thing, but it would not have any effect on the problem being discussed. What needs to happen is for the CDL routines that build the VTOC to ensure that all tracks associated with the volume be accounted for in the VTOC as used, not free. Scott Ledbetter StorageTek -Original Message- From: Don Mulvey [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 8:02 AM To: [EMAIL PROTECTED] Subject: Re: Fw: Linux CDL packs on RVA >I have forwared this discussion to the developers and >they do know about the problem. In SP3, they have set >the DBL1STAR field of the fmt1 DSCB to zero to show >100% full in SP3. The format 1 dscb has a DS1LSTAR field ... last used track&block. Is that what you meant? I would not have thought that setting it to 0 would indicate that the volume was full. Anyway ... looked through code and it gets initialized to zero but doesn't seem to ever get changed or used by any of the tools or dasd drvr code. >However, the bottom line is the same - beware of IXFP >DDSR from MVS against a Linux CDL volume, especially >prior to SP3 and other distributions, depending on >their level. Gotcha. -Don
Re: Fw: Linux CDL packs on RVA
>I have forwared this discussion to the developers and >they do know about the problem. In SP3, they have set >the DBL1STAR field of the fmt1 DSCB to zero to show >100% full in SP3. The format 1 dscb has a DS1LSTAR field ... last used track&block. Is that what you meant? I would not have thought that setting it to 0 would indicate that the volume was full. Anyway ... looked through code and it gets initialized to zero but doesn't seem to ever get changed or used by any of the tools or dasd drvr code. >However, the bottom line is the same - beware of IXFP >DDSR from MVS against a Linux CDL volume, especially >prior to SP3 and other distributions, depending on >their level. Gotcha. -Don
Fw: Linux CDL packs on RVA
I have forwared this discussion to the developers and they do know about the problem. In SP3, they have set the DBL1STAR field of the fmt1 DSCB to zero to show 100% full in SP3. However, the bottom line is the same - beware of IXFP DDSR from MVS against a Linux CDL volume, especially prior to SP3 and other distributions, depending on their level. = Jim Sibley Implementor of Linux on zSeries in the beautiful Silicon Valley "Computer are useless.They can only give answers." Pablo Picasso __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Fw: Linux CDL packs on RVA
I think you should beware of this exposure to RVA space when Linux CDL can be accessed from MVS. Below is a converstation that I had with Scott Lederer at Storage Tech on the Marist forum. If the VTOC showed that then volume was 100% full, there would be no problem, but with it showing 100% free, MVS could let the space assigned to the Linux CDL volume be freed. This message is not flagged. [ Flag Message - Mark as Unread ] Date: Wed, 19 Nov 2003 14:48:40 -0700 From: "Ledbetter, Scott E" <[EMAIL PROTECTED]> (Embedded image moved to file: pic04107.gif)Add to Address BookAdd to Address Book Subject: Re: Linux CDL pack and RVA free space collection. To: [EMAIL PROTECTED] Jim, You are correct in being concerned about this. On an RVA or STK Iceberg or STK SVA (all are the same architecture), the hardware has no knowledge of the logical data structures such as VTOCs, filesystems, directories, etc. It manages everything at a track level. When a dataset is 'deleted' from an MVS volume, normally the only actual change at the hardware level is an update to the track(s) containing the corresponding VTOC DSCBs, and possibly a track in the VVDS and perhaps the user catalog if it resides on the same volume. In order to notify the RVA of the deleted status of the tracks associated with a dataset, the MVS system normally will have an "under the covers" software subsystem running called IXFP (SVAA for STK boxes). The IXFP/SVAA software installs itself at IPL time, and if activated, will send notification to the RVA that all the tracks associated with a deleted dataset are eligible to be reclaimed. The RVA then marks these tracks as deleted and reclaimable inside the RVA. This entire process is called Dynamic DDSR. Here is where things get dangerous. There is also an optional process that a user can run via an address space that can be started to do some management and reporting for the RVA. This process is called Interval DDSR. What happens is that on a periodic basis controlled by a parmlib member, a task in the address space will wake up and 'sniff' every online DASD device known as an RVA or SVA device. The process will look at the VTOC on the volume, and will mark as free EVERY TRACK NOT ACCOUNTED FOR IN THE MVS VTOC. So, if your CDL volume looks lik
