RVA=Ramac Virtual Array. RVA is (was) a disk subsystem engineered by StorageTek and sold by IBM roughly from 1996->2000. It uses a unique log structured file layout to present 1024 3380 or 3390 images to the hosts, while potentially not actually having enough backend disk storage to hold 1024 3390-3's worth of data. Thus the 'Virtual' name. I say 'potentially', because one feature of the RVA is that data is hardware compressed on the channel interfaces as the data is transferred into the box. If the data is compressible enough, you could easily store 1024 volumes worth of data. At a very high level, you can think of it as being similar to virtual memory in an operating system. On a 31-bit OS, you can have hundreds of address spaces that all think they have access to 2GB of memory, while in reality the hardware itself may not even have 2GB of physical memory to work with.
One of the challenges of this type of architecture is communicating to the hardware when a track on a volume is not 'really' being used by the OS or an application. Because the backend disk pool is shared among all of the 1024 volumes at a track granularity, a track of residual data that once belonged to a now deleted file is just taking up space on the backend disk pool. Thus, there needs to be some way for the OS to notify the hardware that a track is really freespace and not valid data. To cut to the chase, the issue is this: there is a process that RVA users can run that will read the MVS VTOC for every online volume and for every single track not covered by a DSCB representing valid data, a command will be issued to the subsystem to return those tracks to the pool of freespace on the backend disk. Those tracks are GONE, and the data ain't coming back. If a volume is a CDL volume, or a VM volume with an OS VTOC, and there is not a dummy dataset entry in the VTOC that covers the entire area of the volume that really contains Linux or VM data, there is a great risk. If the process called Interval DDSR (which runs in an address space on MVS controlled by the user) runs against that volume, you could lose your Linux of VM data. The structure of the control statements for Interval DDSR is such that it is very easy to code them to run against every online volume by default. This is why I recommended that any VM or Linux volumes that might ever be brought online to MVS be specifically excluded from Interval DDSR processing, because no good can come from it. There is a similar process that can run against a minidisk on VM, but that is a command-only process. If a user issues the command against a Linux minidisk, they must specifically direct the process to a minidisk. Everything I have said is applicable to the IBM RVA, the STK "Iceberg" 9200, SVA(Shared Virtual Array) 9393, SVA 9500, SVA V960, SVA V2X, SVA V2X2 and SVA V2XF. It is my understanding that the CDL volume format is actually a product of the IBM provided DASD drivers. The individual partitions and their corresponding cylinder ranges are represented by Format 1 DSCB's in the VTOC. There should be no danger to your Linux partitions under normal circumstances, but I think it would be a great idea for the partitioning code that builds the CDL VTOC to cover the areas not taken by partitions with a dummy dataset. With a CDL volume online to MVS, you do run the risk that the datasets could be accidentally deleted from the CDL volume from the MVS side. This would not delete the partitions themselves, but the next time Interval DDSR ran the data would disappear because they would be seen as freespace. Scott Ledbetter StorageTek -----Original Message----- From: Don Mulvey [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 7:12 AM To: [EMAIL PROTECTED] Subject: Re: Linux CDL pack and RVA free space collection. >Well, I'm not sure if I'm coming or going on this! You and me both :) >I just formatted a volume CDL on another RVA with >SLES8 SP2 and it shows 0% USED and 50,083 tracks FREE! First off ... could somebody tell me what an RVA is? If you just formatted a cdl disk then it should only have 2 dscbs in the vtoc; a type 4 vtoc descriptor and a type 5 freespace descriptor. So the info seems fine. >The other volume I formatted was with SLES8 SP3 and it >showed 100% USED and 0 tracks FREE! Somebody has to ask ... are you sure you typed in cdl rather than ldl? Can you confirm that it is indeed cdl and there isn't a bug that produced an ldl volume? >So the MVS guy wasn't wrong after all! He was looking >at a volume I had formatted CDL with SLES8 SP2. >So this seems to be release dependent and there IS AN >EXPOSURE if you have a lower release that SLES8 SP3. I >don't know what would happen with RedHat. I'll try >that after I get an RHEL3 system running. 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. >Bottom line still seems to be - don't run DDSR on your >CDL formatted volumes! -Don
