Don wrote: > First off ... could somebody tell me what an RVA is
Well, if you have an RVA or if you are curious, read on. If you don't have an RVA or don't care, never mind ;-) It is the Storage Tech Iceberg Technology developed in the late 1980' specially for MVS environments. After the RAMAC III, IBM had a remarketing agreement with Storage Tech to rebrand the device as an IBM 9393 Ramac Virtual Array and was IBM's main dasd offering for mainframes for several years. When shark was announced, the agreement was discontinued. Its a common piece of hardware in may zSeries shops. Today, it is cheap to acquire, so many people still use it. It uses a Log Structured Array to map virtual tracks to the back end raid array hardware. This is analogous to a paging in MVS. As in MVS, a track is not allocated on the hardware until it is written to. The technology is based on several assumptions true for an MVS environment 1) The VTOC extent maps may say the data set has been allocated with so much space, but in reality, only a small park of it is used, and 2) free space really takes up space on a volume, and 3) there are a lot of repeated characters (mostly blanks) on MVS volumes. Typically, MVS volumes may be run at 50% full because of the need to expand without abending a process. In addition, they added space compression, to get the repeated characters compressed out. The net effect is that the REAL hardware space occupied for a volume can be zero (0) to a real full volume. In MVS, the volumes get up to 66% compression of the data and the packs are only 50% full. Storage Tech took this one step further. Since they are do not have to have all the space on a volume reserved on the hardware, they only back the virtual space with a fracture of the real hardware space. For example, on one of my RVA's I have 512 3390-3 volumes defined for a virtual capacity of 1.4 Terabytes. However, the real dasd on the RVA is only 219 GB! So the assumption is that there will be 6.3 "overalloction" of the pack due to compressible data and unused free space. Actually, quite brilliant when you think about it. Remember, this is late 1980's technology when disk drives were still expensive and RAID technology was new. I don't anyone uses this approach now because the disk drives are so cheap. Vendors are using RAID10 now - mirrored raid5, so there is actually twice has much disc hardware that is needed for recovery purposes. If you look at an MVS VTOC, the extent map may show that the pack is full and for conventional dasd and most vendors implementations, the space is reserved, though it may not be actually used. This then brings up question of garbage collection. There is an interface between MVS allocation and the RVA called IXFP in the IBM RVA that communicates allocations and free up of space between MVS and the RVA. There is also dynamic dasd space reclamation (DDSR) that runs periodically, interrogates the VTOC, and frees any free tracks based on the VTOC. This is the exposure that we are talking about. Depending upon what IXFP interrogates in the VTOC, there is a data loss exposure. I have seen no reports that anyone has tested this, just recommendations that you keep your Linux DASD seperate from your other OS. >Somebody has to ask ... are you sure you typed in cdl rather than ldl? Simple to check - if you vary an LDL volume on to MVS, you get an "I/O error" because you do not have a VTOC and it does not come online. If you vary a CDL volume on to MVS, the volume will vary online. Since I could read the VTOC under MVS, it was obviously a CDL volume. To add insult to injury, if you try to allocate an MVS data set to the CDL volume inadvertently, some levels of MVS abend the task and mess up the VTOC so the pack cannot be varied back online. >Doesn't make any sense. If you reformat a volume your >gunna reblock >and >refresh: ipl records, vol label record and the vtoc >itself. A format >doesnt create any type 1 dscbs. If there is a bug >that resulted in an >ldl >volume ... even if you specified cdl ... then this >would make sense. I >am >assuming that RVA (whatever it is) looks for any/all >type 5 dscbs if >the >vtoc track is available. If it thinks the vtoc track >is missing (ldl >volume) then my guess is that it would declare no >datasets and %100 >free. Yes, there is a bug! Since when do bugs make sense? I'm trying to track its extent and what releases of MVS and Linux that might have problems. However, I thought it fair to warn the other RVA users of the potential exposure. ===== 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/
