Hi Tom,

Thanks for the compliment.

Re your question around Zero Page Reclaim, let me see if I can answer…..

Where best results are expected is after migrating a non-DP LUN to a DP LUN.  Lets assume the original non-DP LUN was created as 100GB, but the host only ever wrote to 50GB of it.  There will then exist 50GB of free unused space on that LUN. 

Prior to a LUN being presented to a host it is RAID formatted, this writes zeros to the entire address space of the LUN.  Therefore, because the host has not written to this last 50GB of space, it will still be full of zeros.  Zero Page Reclaim operations can reclaim that space back to the free pool.

This is of course assuming that the filesystem doesn't go and touch all blocks or even a part of them, or that a database hasn't pre-allocated all blocks ahead of actual data writes.

Now assuming there was space that could be reclaimed by Zero Page Reclaim operations…. Because it will only claim back pages that are entirely zeros, the host will be unaware that this operation has happened.  Even if, for whatever reason, the host had purposefully written zeros to large parts of the LUN, and these zeros represented real data, it should not be a problem.  Any time the host tries to access those zeros (that have been taken away from the host and assigned back to the free pool) the array performs an operation that returns a zero to the host – so the host still gets its zero and is blissfully unaware. 

In fact, the host may even get a quicker response as there is no requirement for a back end read to disk including the wait for disk head positioning etc to determine that the data is a zero.  But that is neither here nor there really.

Let me know if that answers your question or not.

Nigel

Hi Bert,

Good point.

What Snig says is obviously correct.  On Hitachi storage this mapping table is generally referred to as the Dynamic Mapping Table, or DMT for short.  It is mirror protected in Shared Memory as well as on disk copies in the first Pool-VOL in the first pool created (may be all pools, Im not 100% sure).  Oh and if you have mode 460 set on the SVP then during a power down of the array an additional copy is also saved to the HDD of the SVP.

Obviously "corruption" doesn't care how many copies you have, it will affect all copies if they are kept in sync.  As far as other protection mechanisms go, Hitachi have not published anything on this to my knowledge.  But I think Snigs comments sum it up well.

I suppose another way of looking at it might be as follows – A typical non DP LUN presentation may look like this -

• The host OS sees a volume, which it writes to as if it were locally attached over a SCSI bus (the specifics are abstracted by the following components)
• The Volume manager has pieced together this volume from multiple LUNs or extents.  It has no doubt performed striping, mirroring and may be some other magic.  All requiring its own mappings/metadata.
• The LUNs are mapped on front end ports on an external storage array over switches and HBAs.  Each of which performs its own mappings of sorts and requires its own metadata.
• On the storage array, parts of the LUN will actually be in dirty queues in cache and other parts resident and up to data on disk.  The storage array takes care of these mappings with more metadata.
• Behind the cache the LUN is created from several slices spread over multiple disks.  Again requiring mapping tables and metadata

As you can tell, this is quite a simplified view and does not take in to account RAID, DP or virtualising external storage…..

Yes, you are absolutely correct, DP does require another layer of mapping.  However, its not something I feel we should worry about.  We just need to understand it and also the fact that we are surrounded my such mappings everywhere we look in IT already.

Back to pen and paper?  Sometimes I do wonder

If those indexes get corrupted, then yes you would have a disaster on your hands.  Not only would you have issues with DP, but everything else going on in the box as well.  So since HDS will give you a 100% data availability guarantee just imagine the protection they put behind that never happening.

Excellent work you are doing to get us to understand HDP and the benefits. I wonder what the experiences on the Zero Page Reclaim feature are, I imagine that not all OS can cope with that, or would not write zeros on unclaimed space, especially Windows, where I would imagine it requires some additional steps, or even reboots? Or any UNIX flavour, like AIX or Soalris, how do they deal with that?

Very courious.

Just for curiousity, if I don’t guess it wrong, there should be tables containing the relationship / indexes of the Pages and the indexes are updated or referred so frequently.  What if those indexes got corrupted? 

Well, I am sure they are well-protected but it seems that a new point of failure is introduced.