× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



And I disagree with one of Steve's statements. See below (I've rearranged some of Steve's comments).
--Paul E Musselman

At 9:36 PM +0000 8/24/17, Steve Pavlichek wrote:
I have to disagree with some of these statements. First of all let's agree on naming conventions of the LPARs

PRODUCTION (your live LPAR)
BACKUP (The copy made from the flash copy).


Any data which is changed on the PRODUCTION LPAR after the flash copy is not known to the BACKUP LPAR.
I agree.

Any data which is changed on the BACKUP LPAR is not known by the PRODUCTION LPAR.
I agree.

After the flash copy has happened, you can treat these as two completely separate copies of the disks. The storage subsystem does its magic to keep track of the changes and minimize the physical amount of disk capacity used.
I agree.

When talking about pointers and amount of disk used, this is all on the storage (assuming you flashed to thin provisioned LUNs).
I agree. The iSeries doesn't know that the SAN is there and playing games with storage.

Another way to think about it is if PRODUCTION sees 10TB of disk capacity(WRKSYSSTS) , BACKUP will see 10TB of disk capacity(WRKSYSSTS), but the SAN may only use a total of 11TB of capacity.
I agree, with just the part I included!

The physical amount of disk space on the SAN used by BACKUP, is directly related to the amount of data blocks which changed on PRODUCTION after the flash copy started. No data is copied between partitions.
I disagree.

As far as the iSeries is concerned, no data is copied between LPARs. However...

The storage used by the SAN for the BACKUP LPAR is the total of size of changes made in both the Production and Backup LPARS. And the Backup LPAR -does- change things-- it marks every object saved with the timestamp of the backup.

The storage space allocated for the PRODUCTION LPAR is broken up into data blocks. A bitmap table has a bit for each block.

There are several possible events:

- Neither LPAR has changed anything in a data block-- No data exists in the Backup LPAR for this block.

- Production LPAR has changed something in a data block-- The data, as it existed before the Production change, is copied to the Backup LPAR before the Production LPAR touches anything. The bitmap bit for this block is set to "block copied."

- Backup LPAR has changed something in a data block-- The data, unchanged in the Production LPAR, is copied to the Backup LPAR, then the Backup LPAR updates the copy of the block. The bitmap bit for this block is set to "block copied."

If either LPAR plans to change a block, the Bitmap Bit is checked first-- if the data has already been copied, the update proceeds without copying anything.

The size of the data in the SAN for the BACKUP LPAR is thus the sum of changes in both LPARs.

The data is duplicated in blocks, not bytes. The SAN has a bit table with one bit for every block of data in the LPAR. So if you're planning to change 10 bytes in a data block, the entire block is copied to the Backup LPAR. Then your 10 bytes is updated. If the same data space in the Production LPAR has already been updated, there is already a copy of that data in the Backup LPAR; it is only copied once.


--Paul E Musselman




From: Musselman, Paul<mailto:pmusselman@xxxxxxxxxxxxxxxx>
Sent: Thursday, August 24, 2017 5:15 PM
To: Midrange Systems Technical Discussion<mailto:midrange-l@xxxxxxxxxxxx>; midrange-l-bounces@xxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxx>
Subject: RE: Where do I learn about SAN backup?

Joe said:

Okay, this is making some more sense.

When you IPL the flash copy LPAR, everything is just a pointer to the existing production LPAR (until it changes). <--- correct

If you didn't change a single block of data on production, you'd in effect have nothing but
pointers to that data. Until you changed something on the flashed partition. <--- Correct, as long as nothing changes the live data

So you have:

Data that has not been changed on either partition <-- this data lives in the live partition
Original version of data that has since been changed on production <-- this is copied to the Flash partition
Data that has been changed on the copy partition <--- copied from live to flash before it is changed on the flash partition

And some serious magic that keeps it all in order. <--- it's all in that bitmap and a couple of simple rules!

So it would seem that you have to be careful not to touch your production data
in the flash copy partition until after you back it up. <--- but usually only the jobs backing up the data run in the flash partition!

If you for example cleared a master file [IN THE FLASH PARTITION] and then backed it up on the flash copy, my guess would be it would be as if you cleared it on production and backed it up. <--- correct

If you for example cleared a master file [IN THE LIVE PARTITION AFTER YOU MADE THE FLASH COPY]
and then backed it up on the flash copy, <-- you'd still have a complete copy of the data!

But even so, that's pretty fantastic stuff.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.