< I am replying in-line >
-----Original Message----- From: Mark Simmons [mailto:mds@gbnet.net] Sent: Tuesday, June 08, 2004 7:45 AM To: SKIP HOFMANN Cc: 'avarni@tech.cj.com'; Waters, G Scott THE LOG.SEC TEAM; Borders, Rich; toasters@mathworks.com Subject: Re: Defraging the excahgne DB
Turning the question around, why would it not be safe to defragment a file on the filer?
Filer defrag requires two things ( as a general rule ):
20 percent volume space free, and no snapshots. The rest is shuffling blocks into a more application friendly pattern.
From the point of view of the client nothing should change surely?
If you do offline defrags and meet the above requirements, you will effectively have an offline application and a well organized 'efficient' database afterwards.
If it did, that would be a fairly significant problem with all files, not just Exchange's database.
Technically, you can defrag a file, or the volume. The wafl scan reallocate function is trying to get the blocks closer to their layer 0 and one pointers. Defrags are really only a problem if you don't get the first two pre-req's right.
SKIP HOFMANN wrote:
If you use Waffle scan then this defrags the entire vol
right?
See above.
And if so is
it safe to use on your exchange DB?
Yes.
At least on 6.3.2 -- I've noticed that WAFL SCAN REALLOCATE will 'pause' indefinately IFF you're over your snapshot reserve.
It is usually a funciton of not finding any blocks that aren't in worst fragmented shape that what you are already in. A factor of 20% free volume space with NO snapshots all but ensures this will not happen.
Otherwise
I've run this many times with no problems. Make sure you aren't over your snapshot reserve and your scan should 'continue'.
You should have no snapshots.
On Mon, 7 Jun 2004, Waters, G Scott THE LOG.SEC TEAM wrote:
] ] WOW ... this is the exact opposite of what NetApp support told me. ] ] On a volume used for storing Exchange data, the WAFL SCAN
REALLOCATE
command ] will never complete.
No one in NGS support should have told you it will never complete. In 6.3 and greater, it was more optimized and cleaned up, but that was a testamanet to the way block handling was done and some major efficiencies that were built into the OS of Data OnTap.
It goes for a while and then stalls.
See above.
] We monitor the layout ratios weekly and schedule down time
to perform an
] offline DEFRAG every 4 - 6 weeks.
The remarkable thing about an offline defrag is that it effectively copies the entire mailstore in application defrag back to the Filer. This means that the application is defraged as it is written. The wafl is defragged due to the nature of the blockmap and nvram/journaling. It is almost perfect.
] This is all based on information received at the time ...
If NetApp has
] fixed this then someone enlighten me.
It is fixed, and getting better. Keep your eye open as there will be some new things to come also.
I would also like to offer a thinking 'outside the box' and say that it is a cool idea to QSM the mail store from one volume to another since a QSM is a process that is going to defrag on WAFL ( not application though ) and then update on a scheduled basis. Once snapmirrored, you can stop and quiesce the application, then quiesce and break the QSM and that makes the destination read / writable. You point the exchange server to the destination, and voila, you have a reallocate and only a short downtime.
] ] - Scott W.
That is all for now.
/rich