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.  ;-)
  

-- 
-- jetez un oeil ici http://www.sensiva.com/ --
--  have a look here http://www.sensiva.com/ --