[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tru64-unix-managers
Subject:    To defragcron or not to defragcron?
From:       "Speakman, John H./Epidemiology-Biostatistics" <speakmaj () MSKCC ! ORG>
Date:       2003-09-30 15:12:17
[Download RAW message or body]

All

Related to the flurry of messages I have posted recently and an e-mail
exchange with Martin, I'm now a bit confused about the general best
practices regarding defragcron.  I'm clear that in a cluster, only one
member should be defragging one volume at once, and that I should steer
clear of CFS volumes containing Oracle tablespaces as they are
pre-allocated anyway.  But beyond that, is the prevailing wisdom:

- With the above provisos, go ahead and defragcron
- Don't ever defragcron, maybe defragment manually once in a blue moon
if ever
- Do defragcron, but only schedule it say once a week at a nice quiet
time
- Do defragcron, but not on any CFS or otherwise shared volumes

Or something else?  Does it depend on your OS version?  We are running
5.1A in production and 4.0F in other places.  I know 5.1B has vfast but
we are not in a rush to go there.

Thanks; I will summarize.

John

 
     =====================================================================
     
     Please note that this e-mail and any files transmitted with it may be 
     privileged, confidential, and protected from disclosure under 
     applicable law. If the reader of this message is not the intended 
     recipient, or an employee or agent responsible for delivering this 
     message to the intended recipient, you are hereby notified that any 
     reading, dissemination, distribution, copying, or other use of this 
     communication or any of its attachments is strictly prohibited.  If 
     you have received this communication in error, please notify the 
     sender immediately by replying to this message and deleting this 
     message, any attachments, and all copies and backups from your 
     computer.


[prev in list] [next in list] [prev in thread] [next in thread]