|
Home > Archive > Data Storage > November 2004 > snapshot schemes in emc and netapp
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
snapshot schemes in emc and netapp
|
|
| vidyesh 2004-08-25, 4:16 am |
| my underestanding is tht netapp snapshots are almost a zero penalty
scheme while those with emc put a heavy penalty. here is why
netapp snapshot scheme
block a from active file system has to be changed to a1. the
operations are as below
find a new free block <which is very fast due to wafl>
write the new data a1 there
change the pointer in the inode table of the active file system which
pointed to a to point to new block a1
1 data write , 1 freeblock seek , 1 pointer change in inode table is
what it takes
emc snapshot scheme
block a from active file system has to be changed to a1. the
operations are as below
read block a
find a new free block
copy the data from a there
write the new data a1 to the original location of block a
1 block read , 2 block writes , 1 freeblock seek is what this takes
this is around 3 times as slower than that of netapps
is that correct
any other perspectives on these 2 snapshot schemes
thanks in advance
vidyesh
| |
| Faeandar 2004-08-25, 5:45 pm |
| On 25 Aug 2004 02:10:38 -0700, vidyeshk@gmail.com (vidyesh) wrote:
>my underestanding is tht netapp snapshots are almost a zero penalty
>scheme while those with emc put a heavy penalty. here is why
>
>netapp snapshot scheme
>
>block a from active file system has to be changed to a1. the
>operations are as below
>
>find a new free block <which is very fast due to wafl>
>write the new data a1 there
>change the pointer in the inode table of the active file system which
>pointed to a to point to new block a1
>1 data write , 1 freeblock seek , 1 pointer change in inode table is
>what it takes
>
>emc snapshot scheme
>
>block a from active file system has to be changed to a1. the
>operations are as below
>
>read block a
>find a new free block
>copy the data from a there
>write the new data a1 to the original location of block a
>
>1 block read , 2 block writes , 1 freeblock seek is what this takes
>
>this is around 3 times as slower than that of netapps
>is that correct
>any other perspectives on these 2 snapshot schemes
>thanks in advance
>vidyesh
No perspective on the EMC snapshot scheme but you are correct about
NetApp. They have made the most efficient snapshot scheme to date,
and they will be happy to tell you all about it. 
~F
| |
| Jim85CJ 2004-08-25, 5:45 pm |
| Yes, netapp snaps have very low overhead because they own the filesystem
(and hence the inode table). EMC (and all block-based storage arrays)
do not have visability to the filesystem. Of course, EMC arrays with
snapshots are probably no slower than netapp :-)
Faeandar wrote:
> On 25 Aug 2004 02:10:38 -0700, vidyeshk@gmail.com (vidyesh) wrote:
>
>
>
>
> No perspective on the EMC snapshot scheme but you are correct about
> NetApp. They have made the most efficient snapshot scheme to date,
> and they will be happy to tell you all about it.
>
> ~F
| |
| Jesper Monsted 2004-08-27, 5:46 pm |
| vidyeshk@gmail.com (vidyesh) wrote in
news:9cef376a.0408250110.668643ff@posting.google.com:
> my underestanding is tht netapp snapshots are almost a zero penalty
> scheme while those with emc put a heavy penalty. here is why
[snip]
Looks about right. You only forgot one thing: You write to cache, the box
takes care of the rest, without you ever noticing a thing.
If you start running out of cache, it's another problem, but for the
majority of work, snaps on symm/clariion has little to no impact on your
performance.
--
/Jesper Monsted
| |
|
| Maybe for the *nix platforms, but for Windows, StorageCraft Volume Snapshot
is the best; and we do not own the file systems.
www.storagecraft.com
Jamey
"Faeandar" <mr_castalot@yahoo.com> wrote in message
news:eempi05j8mihi8rs417kmu0vpfetsu7j35@
4ax.com...
> On 25 Aug 2004 02:10:38 -0700, vidyeshk@gmail.com (vidyesh) wrote:
>
>
> No perspective on the EMC snapshot scheme but you are correct about
> NetApp. They have made the most efficient snapshot scheme to date,
> and they will be happy to tell you all about it.
>
> ~F
| |
| JT Johnson 2004-10-16, 2:45 am |
| "Jamey" <jkirby@tfb.com> wrote in message news:<10m5vas99d39ida@corp.supernews.com>...[vbcol=seagreen]
> Maybe for the *nix platforms, but for Windows, StorageCraft Volume Snapshot
> is the best; and we do not own the file systems.
>
> www.storagecraft.com
>
> Jamey
>
>
> "Faeandar" <mr_castalot@yahoo.com> wrote in message
> news:eempi05j8mihi8rs417kmu0vpfetsu7j35@
4ax.com...
One note on Snapshots between these two vendors. NetApp has a zero
overhead (pointer based) Snapshot for a CIFS/NFS NAS volume. A first
time snap requires zero overhead. Each additional "incremental" snap
requires the space equal to the amount of changed blocks only.
However, until the new version of Data ONTAP comes out (I guess it's
due out in November), LUN snapshots will require 100% overhead of the
size of the LUN. You might only have 100 gig of data on a 2 terabyte
LUN but the snap will require 2 terabytes of reserved disk for the
snap. The new version is suppose to support snapshot reserves for the
amount of data only and not the entire LUN.
EMC CXxxx lines require 100% overhead for snapshots no matter how it's
used. Unless they came out with something new within the last month.
| |
| Thanatos 2004-11-24, 8:45 pm |
| JT,
Sorry but you are VERY wrong, about NetApp LUN snapshots requiring 100%
space overhead.
LUN's on NetApp are simply container files on top of WAFL. Snapshot's of
LUN's are like snapshots on any WAFL volume - no space is consumed until
data is written, regardless of (optional) space reservations. Overhead of
10-30% is typical depending on application rate-of-change characteristics
and backup/retention windows.
Stotek Iceberg was similar, being block based but always redirecting writes
to new locations. The problem for Iceberg/SVA was the compression which
killed performance due to both codec overhead and the non-linear
relationship between real and virtual blocks. NetApp LUN's have a 1:1
relationship between real and virtual blocks which makes virtualisation
overhead negligible.
Jamie: I don't know how StorageCraft's snapshots work (yet), but if they
ALWAYs redirect writes like NetApp they have the potential for zero-overhead
snapshots; if they don't there will be a penalty.
"JT Johnson" <jtjohnson@faegre.com> wrote in message
news:b09ab426.0410121132.378cee5b@posting.google.com...
> "Jamey" <jkirby@tfb.com> wrote in message
news:<10m5vas99d39ida@corp.supernews.com>...
Snapshot[vbcol=seagreen]
>
>
>
> One note on Snapshots between these two vendors. NetApp has a zero
> overhead (pointer based) Snapshot for a CIFS/NFS NAS volume. A first
> time snap requires zero overhead. Each additional "incremental" snap
> requires the space equal to the amount of changed blocks only.
> However, until the new version of Data ONTAP comes out (I guess it's
> due out in November), LUN snapshots will require 100% overhead of the
> size of the LUN. You might only have 100 gig of data on a 2 terabyte
> LUN but the snap will require 2 terabytes of reserved disk for the
> snap. The new version is suppose to support snapshot reserves for the
> amount of data only and not the entire LUN.
>
> EMC CXxxx lines require 100% overhead for snapshots no matter how it's
> used. Unless they came out with something new within the last month.
| |
| Faeandar 2004-11-24, 8:45 pm |
| On Thu, 25 Nov 2004 04:33:23 +1100, "Thanatos" <dgahan@europe.com>
wrote:
>JT,
>
>Sorry but you are VERY wrong, about NetApp LUN snapshots requiring 100%
>space overhead.
>
>LUN's on NetApp are simply container files on top of WAFL. Snapshot's of
>LUN's are like snapshots on any WAFL volume - no space is consumed until
>data is written, regardless of (optional) space reservations. Overhead of
>10-30% is typical depending on application rate-of-change characteristics
>and backup/retention windows.
>
>Stotek Iceberg was similar, being block based but always redirecting writes
>to new locations. The problem for Iceberg/SVA was the compression which
>killed performance due to both codec overhead and the non-linear
>relationship between real and virtual blocks. NetApp LUN's have a 1:1
>relationship between real and virtual blocks which makes virtualisation
>overhead negligible.
>
>Jamie: I don't know how StorageCraft's snapshots work (yet), but if they
>ALWAYs redirect writes like NetApp they have the potential for zero-overhead
>snapshots; if they don't there will be a penalty.
>
I think the 100% overhead on NetApp LUN's is correct. I recall my
NetApp SE talking about this, and at least for now (though there are
plans to change it) it's a complete copy. I'll see if I can find the
doc's on this and post them.
~F
>
>"JT Johnson" <jtjohnson@faegre.com> wrote in message
>news:b09ab426.0410121132.378cee5b@posting.google.com...
>news:<10m5vas99d39ida@corp.supernews.com>...
>Snapshot
>
| |
| Faeandar 2004-11-24, 8:45 pm |
| On Wed, 24 Nov 2004 17:54:57 GMT, Faeandar <mr_castalot@yahoo.com>
wrote:
>On Thu, 25 Nov 2004 04:33:23 +1100, "Thanatos" <dgahan@europe.com>
>wrote:
>
>
>I think the 100% overhead on NetApp LUN's is correct. I recall my
>NetApp SE talking about this, and at least for now (though there are
>plans to change it) it's a complete copy. I'll see if I can find the
>doc's on this and post them.
>
>~F
Oy. I have not been able to find it so I'll defer. I think it may
still be true but I'm too lazy to look further.
~F
[vbcol=seagreen]
>
|
|
|
|
|