Giving the benefit of the doubt, perhaps the EMC reps were talking only about when the SnapView is initially created. However, they certainly utilize a "copy-on-first-write" procedure for subsequent changes to the active file system. For more details:
http://www.emc.com/pdf/products/clariion/SnapView_DS.pdf
The impact on performance, of course, depends entirely on your environment. In many cases it may be indistinguishable from NetApp because the rate of data change in the filesystem is relatively small.
To conduct another fishing expedition for the EMC lurkers among us, I assume that with SnapView/IP (like TimeFinder) you can "split-off" a SnapView (like a BCV) for various purposes. True? This creates a capacity planning issue, but may be a valuable capability, depending on your requirements.
Joe
Joe Luchtenberg Dataline, Inc. 757.858.0600 757.285.1223 (cell) 757.858.0606 (fax) joe.luchtenberg@data-line.com www.data-line.com
-----Original Message----- From: Martin Hughes [mailto:Martin.Hughes@Halliburton.com] Sent: Thursday, May 10, 2001 12:45 PM To: toasters@mathworks.com Subject: RE: EMC IP4700 vs NetApp F740
Your description of how the IP4700's Snapshot copy-on-write
mechanism works
is right on. The original data is copied to a new location
and the new data
is written to the original block. Yes this compromises
performance. Yes
you have to allocate physical disk space to accomplish this.
No you cannot
shrink the amount of disk space you have allocated for this
process if you
find that it is too much.
Hmm, not according to a demo we had from EMC week before last. I grilled them pretty hard on that and they claimed that they updated the inode file only and did not copy blocks to another location.
Well, we have an eval unit coming in next week and I'll do some testing.
Regards
Martin Enterprise Storage/Enterprise Server Group mailto:martin.hughes@halliburton.com cellphone: +1 713 303 9214 office: +1 281 871 4124
-
Joe Luchtenberg