In a typical solution you lose 10% for WAFL overhead (disk serialization, mbr, etc). You then lose 5% for aggregate snap reserve and 20% for volume snap reserve. Actually, you don't lose the snap reserve space - this space is reserved to ensure enough space for typical snapshots (think of them as online backups). The snap reserve space can be changed. For instance, I always set the aggregate snap reserve to 0% -- I cannot foresee any situation where I would want to snap restore an entire aggregate. These numbers are for NAS. If you are using SAN (iSCSI or FCP LUNs) then you lose 50% of available space to be able to accommodate at least one full snapshot of the LUNs. To someone first starting out with NetApp solutions, these numbers sound horrible, I know I did. However, now that I've been using them for a few years I love it. The flexibility you get in disaster recovery, transferring data to other filers, etc is very much worth the tradeoff.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of margesimpson@hushmail.com Sent: Wednesday, July 26, 2006 9:38 PM To: toasters@mathworks.com Subject: Storage space overheads!
Hi all: Can anyone please give me total NetApp overheads including, file systems, aggr reserve, snap reserve, wafl overhead, parity disks (raid_dp), etc, etc. say, 10 x 100GB = 1000GB total. what usable space should i finally get after all those overheads.
Can anyone give me proper figures/ math and proper break up of above figure?
I heard NetApp solution has lot of disk overheads!
Thank you in advance. Marge.
Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480
Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485
Re. aggregate snapshots - you need them (actually, it is required) for SyncMirror. Also it makes sense to disable snapshot schedule for aggregates (yes, it does exist as well as for volumes). Setting aggregate snap reserve to 0% alone does not disable snapshot generation.
-andrey
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Holland, William L Sent: Thursday, July 27, 2006 1:22 PM To: margesimpson@hushmail.com; toasters@mathworks.com Subject: RE: Storage space overheads!
In a typical solution you lose 10% for WAFL overhead (disk serialization, mbr, etc). You then lose 5% for aggregate snap reserve and 20% for volume snap reserve. Actually, you don't lose the snap reserve space - this space is reserved to ensure enough space for typical snapshots (think of them as online backups). The snap reserve space can be changed. For instance, I always set the aggregate snap reserve to 0% -- I cannot foresee any situation where I would want to snap restore an entire aggregate. These numbers are for NAS. If you are using SAN (iSCSI or FCP LUNs) then you lose 50% of available space to be able to accommodate at least one full snapshot of the LUNs. To someone first starting out with NetApp solutions, these numbers sound horrible, I know I did. However, now that I've been using them for a few years I love it. The flexibility you get in disaster recovery, transferring data to other filers, etc is very much worth the tradeoff.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of margesimpson@hushmail.com Sent: Wednesday, July 26, 2006 9:38 PM To: toasters@mathworks.com Subject: Storage space overheads!
Hi all: Can anyone please give me total NetApp overheads including, file systems, aggr reserve, snap reserve, wafl overhead, parity disks (raid_dp), etc, etc. say, 10 x 100GB = 1000GB total. what usable space should i finally get after all those overheads.
Can anyone give me proper figures/ math and proper break up of above figure?
I heard NetApp solution has lot of disk overheads!
Thank you in advance. Marge.
Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480
Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485
-
Borzenkov, Andrey (FSC) -
Holland, William L