It looks to me like you're both right. If I may paraphrase:
Ed: "snapshots are handy for immediate user-initiated file recovery"
Curtis: "in the described configuration, those snapshots will likely
consume lots of space"
Maybe I'm missing some subtext here but I agree with, and see no
conflict between, the above two statements. :-)
time for the feats of strength!
rob
2008/12/13 Curtis Preston <cpreston AT glasshouse DOT com>:
> Ed Wilts said:
>
>>Snapshots appear to be full copies of the file system, whether anything has
>> changed or not.
>
>>It doesn't matter if you're modifying files, deleting files, or completely
>> overwriting them.
>>It's a good thing you're a backup expert and not claiming to be a NetApp
>> expert :-)
>
> I know quite a bit about NetApp and have even been accused a time or too of
> being a NetApp bigot. Want me to give you a lecture on how WAFL works? ;)
>
>
>
> What I'm concerned about is how much space each snapshot will take up.
> Let's cover one extreme.
>
>
>
> Put 10000 1KB files on the filer
> Take a snapshot.
> Delete those 10000 files from the filer
> Add 10000 more 1 KB files on the filer
> Take a snapshot
> Repeat
>
>
>
> Each snapshot will take up 10 MB (10,000 KB) of space
>
>
>
> Here's another extreme.
>
>
>
> Put 10000 files on the filer
> Take a snapshot.
> Modify each of the 10000 files, with a 1 byte modification each time
> Take a snapshot
> Repeat
>
>
>
> Each snapshot in this scenario will take up 10 KB (10000 bytes), regardless
> of the size of the original filer.
>
>
>
> If each day he backs up the SQL dump, he deletes yesterday's file then makes
> a new one, he's behaving like the first extreme and each snapshot will take
> up the size of the SQL dump. If he overwrites the same file every day, he
> has a better chance of being closer to the second extreme. But, what I've
> SEEN is that in the scenario where you are completely overwriting the file
> each time (as you would in a SQL dump), it can cause the first extreme and
> not behave like the second extreme. It depends on the application and how
> they lay down the data. If how they lay down the data makes it look like
> they've just modified the file, then the filer will act closer to the second
> extreme. If the overwriting of the file "scrambles" it in such a way that
> it moves all the blocks around, each day's snapshot will take up the same
> space as a full SQL dump. (BTW, the quickest way to guarantee the latter,
> in my experience, is to run that SQL dump through compression. Just like
> compression messes up dedupe, it also messes up the way NetApp looks at the
> file to find differences.)
>
>
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail.
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
