SUMMARY: defragment keeps running...and running...and running...

From: Dan Harrington (dan.harrington@av.com)
Date: Mon Jul 22 2002 - 08:55:55 EDT


The consensus was to chill out and let the tool run its course, with
caveats that A) yes, it can take a very long time, and B) lots of file I/O
will tend to keep it running longer. I was also advised that one can
certainly kill the process (^C or 'kill -TERM <pid>') if you reach the
limits of your patience.

Thanks for the responses from A. Mahendra Rajah, Rich Keller, Alan Nabeth,
Tom Blinn, and Pat O'Brien. Excerpts follow:

"I've read that there are circumstances where defragment can take a very
long time. Sometimes it can be due to bugs that prevent it from realizing
that it can't do better. In other cases it can be due to not having enough
free space to create enough contiguous space for that "one last" file
movement that would allow it to finish. For a version as old as V4.0F you
have to consider both as a possibility."

"I have seen pass 43 in day 3.5 in the past., so not to worry. you can
control"c" and break, and it will exit. Usually perf is beeter after a run
similiar to yours. wish I could run defragment. it crashes my 5.1 pk 5
system in 16 minutes."

"It can take a LONG time. Unless there is no activity of any kind in the
file system, things can change.. and depending on just what flags you gave,
it might keep going. Just control-C out if you are happy with where it's at
-- it traps the signal (SIGINT) and exits cleanly."

Dan

[Original query below...]
>How long should one expect a defragment session to run? I started running
>it yesterday on an AdvFS domain consisting of 3 volumes (2 of 36GB, 1 of
>160GB) on an HSZ70 controller. The system is a member of a TruCluster
>(V4.0F, ASE1.6). Before running defragment, I had checked (via the flags
>"-n -v") that the average extents per files w/ extents was 7.9 (aggregate
>I/O performance was 59%).
>
>At this point it has been running slightly over 24 hours, and is currently
>on Pass 8. Back on Pass 6 the average extents per files w/ extents got
>down to 1.0, and aggregate I/O performance was 100%. Why wouldn't it have
>exited cleanly at that point?
>
>Dan



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:46 EDT