Hi Rob,

FC/iSCSI LUN's in DataONTAP (DOT) implementation differs from CIFS/NFS qtrees in that they are block based rather than file based since LUN's need to be accessed in that manner on the client sides.

Hence LUN snapshot is a misnomer. It is actually a mirrored LUN of the original, in more conventional terms. Thus it requires 100% more storage space for each "snapshot" per LUN. The additional 20+% in my understanding is the buffer space DOT needs to cache the block IO's. I think this 20% is per volume but it will increase if there are many LUN's and much IO activity. I was advised to leave at least 30% to accommodate such IO-intensive situations.

Since the snapshot is a mirrored LUN, any block change in the original LUN is propagated to the snapshot in due time, i.e., after being cached/buffered first before written to disks. You can certainly reduce this buffer space down but at your own risk as usual since it will impact performance of the original LUN by taking away buffer/cache improvement for it not to mention that of the snapshot IO process.

I have not created 28-disk RAID-DP volumes yet but have investigated this option for one of our Engineering efforts. A special license is required since it is not normally recommended either for technical rational or business justification, i.e., to sell more disks for parity usage. From the white papers that I read, DOT LUN is still based on WAFS, thus the need for 20 - 30% disk based buffer. This could be the reason Net App PS advises of lack of significant difference in operational functionality and performance between the 28- and 14-disk RAID DP.

At the same time with more disks in a LUN, reconstruction in theory should either consume more CPU cycles or take longer for both orthogonal and diagonal (these are my own terms for the lack of official terminology that I have found so far) parity calculation since there are more spindles and blocks to go through for RAID-DP. So I will expect longer rebuild time for 28-disk set than 14-disk one. At the same time, RAID-DP plus at least a hot spare should decrease the possibility of the need for such reconstruction to practically zero short of catastrophic disasters according to Net App literature, so maybe that's why the difference here is not practically significant.

Pou

RE:

Imagine my surprise upon discovering that the space reservation for LUN snapshots is 120%, instead of 20% to 30% for a file system. I think I understand why. I wonder what the practical field experience is with trimming that figure down to something the guy who paid for the NetApp will accept.

Specifically, if what is on the LUN is a relatively stable NTFS file system, is "blocks changed" similar enough to "files changed", or are there "catastrophic events" that go out and touch many disk blocks at once, thus mandating the huge space reservation?

If you under-allocate the reservation, then all disk blocks are suddenly written to, can you configure the NetApp to release the snapshots and commit the writes, or must it look like a premature disk full condition?

It seems like a much more economical path will be to ignore the SnapDrive approach, ignore snapshots, and just use Volume Shadow Copy on the windows servers hosting the filesystem. This would get my space reservation back down to 20% to 30%. Any thoughts?

Oh, a bonus question: I had a NetApp PS guy recommend 28-disk RAID-DP over 14-disk RAID-DP, saying that there is absolutely no significant difference in re-build time or any other down side. Any thoughts on that?

Thanks!

/// Rob

Rob Winters SAIC, NASA Headquarters ISEM Contract