Unsolved
This post is more than 5 years old
1.4K Posts
0
1856
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.
Richard_Butler
84 Posts
1
June 9th, 2011 07:00
Hello,
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:
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.
zhouzengchao
1.4K Posts
0
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....
Richard_Butler
84 Posts
0
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
HelloWorld
#
# ls -lut
total 2
-rw-r--r-- 1 root root 11 Jun 17 12:51 my_file
Here are the relevant points:
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.
zhouzengchao
1.4K Posts
0
July 2nd, 2011 23:00
thank you Richard for your great help!