Start a Conversation


This post is more than 5 years old


June 8th, 2011 18:00

Would Reserved LUN get 64KB write I/O only?

Hi all,

i have a question regarding Reserved LUN. As we know, it is used by snapshot to store COFW writes data. all the data chunk to the reserved LUN would be 64KB. But when i doing study and take some practice exam, i was told that it was possible that other wirte I/O size might be occur on the reserved LUN, like 8KB or something else. Is it true and under what condition would this occur?

thank you in advance.

June 9th, 2011 07:00


The actual replication block size may vary between replication products, but 64KB is probably a good example. Within EMC we tend to concentrate on array based replication and network based replication, but there are also many local/remote replication products hosted in UNIX kernels (eg Solaris Instant Image for local replication and Solaris StorEdge Network Data Replicator for remote replication).

The reserved LUN effectively represents a PIT image/snapshot. This image can be enabled so that it can be accessed by a host (eg. for testing binaries, for decision support, for backup to tape etc etc). The relevant point here, is that this enabled image is available for both reads and writes. The application that is writing to the image might be using a block size of 4KB (for example, maybe the application is a filesystem with a 4KB block size). There can be one of two general scenarios when the application writes to the image:

  • application issues a 4KB SCSI write (for example)
  • array microcode (array-based) or host kernel (host based) replication driver intercepts the write I/O
  • replication driver checks the 'Copy' bit map
  • IF  Copy_On_First_Write has already occurred for the 64KB block
  • THEN
    • complete application 4KB write to the 64KB block
  • ELSE
    • copy 64KB block from production to reserved LUN
    • complete application 4KB write to the 64KB block
  • END_IF

Also worth noting, is the point that the application can issue writes to the PIT snapshot that are smaller than the replication block size (4KB vs 64KB in my example above). Exactly how this equates to the final write that the replication driver issues to the reserved LUN itself may, I expect, depend on cache, memory, buffering and other internal algorithms etc.

Sometimes, the first time you look at this, it seems surprising that you can issue writes to the PIT image. Depending on the product you may need to understand that the image is now diverging from the PIT it was created, and at any time in the future the image will represent the PIT plus any writes that have been made from the test system. Having said this, some products allow you to discard/ignore the writes when the image access is disabled (effectively returning the image to the exact PIT).

I hope this makes sense.

Best regards, Richard.

1.4K Posts

June 13th, 2011 05:00

Hi Richard,

thank you for the reply. You are right, snapshot itself will get incoming writes from hosts also. That's explained other possible I/O size. But I'm still a litter confusion on this exam pratice. In this case, we are using snapshot for backup purpose. If we don't present the snapshot to the backup host, will it receive other size of I/O? Even we present it to the backup host, will backup application write data to the snapshot? Even so, are we able to calculate the I/O size and IOPS to the RL? In my case, the answer is YES. I don't understand how....

June 17th, 2011 05:00

Hello again,

Let me try and give a specific example of a situation where a 'read-only' application can actually result in a write. I'm going to use a small amount of UNIX to illustrate this. Have a look at the commands below:

# date

Fri Jun 17 12:50:02 BST 2011


# ls -lut

total 2

-rw-r--r--   1 root     root          11 Jun 17 12:49 my_file


# sleep 60;  cat my_file



# ls -lut

total 2

-rw-r--r--   1 root     root          11 Jun 17 12:51 my_file

Here are the relevant points:

  • the date command shows the system time as 12:50:52
  • we use the 'ls -lut' command to show the last access time of a file - it is 12:49
  • we then wait 60 seconds
  • we the run the 'cat my_file' command
  • the 'cat' command is documented to read sequentially through the file - a read-only command
  • we then re-issue the 'ls -lut' and notice now that the access time has changed to 12:51.

Now the access time for a file is actually meta-data that is also stored in the file system (in the files i-node). So, the read-only 'cat' command has actually resulted in a write to the filesystem. Just as one example, it is possible that a filesystem backup agent can result in metadata updates (writes) to the filesystem.

Best regards, Richard.

1.4K Posts

July 2nd, 2011 23:00

thank you Richard for your great help!

No Events found!