if your Filer support CIFS client with office kind application you could think of using the following option :
* options cifs.snapshot_file_folding.enable on*
(by default, the option is turned off) as you certainly know Windowz use to create a copy of the document on which you want to work then if you save your work, Windoz erase the original and rename the temporary file of the original name this is the windoz way to work on office files (word, excel,...) the problem with this implementation is if you open a file to just change one word the whole file is rewritten on Filers, this has an impact on snapshot because the whole previous version of the file needs to be protected by the last snapshot
the option I advise you is an Ontapp mechanism to limit this unfeature in trying to recover actual blocks of the file from the snapshot this way, snapshot usage could be limited
hth
Brian Tao wrote:
I think most any Netapp admin has been in this situation: you set aside a chunk of disk space for your snapshot reserve. After a week goes by, you see that the reserve is at 150% of allocation. You manually delete some snapshots until it falls back under 100%, and adjust the snap schedule. A few months go by, new applications are rolled in and old ones retire. Snapshot usage has also increased, but you are at a loss to pinpoint the exact cause of the higher data turnover rate.
What do people do to shed more light on this kind of situation? I'd love to be able to conclude "It is the files in /vol/vol0/myapp/data that are chewing up the most snapshot space" or "It is the write activity coming from NFS client myhost1 that is causing the most block turnover". I think I asked this question about five years ago and did not discover an adequate solution back then. I'm hoping someone might be able to share their expertise on this problem now. ;-)