Has anyone ever had disk defragmentation hang on them? Any idea why?

[jim]

Windows XP SP3
1.7g Intel single core
Computer Management --> Disk Defragmentation

Has anyone ever had disk defragmentation hang on them? Any idea why?

About 3AM, I started a disk fragmentation of a 250G Seagate and went back
to bed.

I have done this process on that disk several times over the past 4 years
and it takes between 2 and 3 hours.

At 6AM I checked it and it was at 23% and moving a .tib file. I went back
to bed.

At 7AM+ it was still at 23% and FWIW, was still moving the same .tib
backup file of 75meg.

I paused it for about 30min., and then resumed it, paused it, and stopped
it.

I closed the defrag program and gave it 10 minutes or so to finish
completely and clean up and then I put the machine into restart. Windows
closed, but it hung and did not go into restart (That was unusual
behavior, but not original)

I crashed it. Disconnected power, drained BIOS by holding the start button
in 20 seconds and it restarted normally. (all of that may have been
unnecessary, but i wanted a clean, cold start.)

Any ideas?

Jim

 

[David H. Lipman]

Windows XP SP3
1.7g Intel single core
Computer Management --> Disk Defragmentation

Has anyone ever had disk defragmentation hang on them? Any idea why?

About 3AM, I started a disk fragmentation of a 250G Seagate and went back
to bed.

I have done this process on that disk several times over the past 4 years
and it takes between 2 and 3 hours.

At 6AM I checked it and it was at 23% and moving a .tib file. I went back
to bed.

At 7AM+ it was still at 23% and FWIW, was still moving the same .tib
backup file of 75meg.

I paused it for about 30min., and then resumed it, paused it, and stopped
it.

I closed the defrag program and gave it 10 minutes or so to finish
completely and clean up and then I put the machine into restart. Windows
closed, but it hung and did not go into restart (That was unusual
behavior, but not original)

I crashed it. Disconnected power, drained BIOS by holding the start button
in 20 seconds and it restarted normally. (all of that may have been
unnecessary, but i wanted a clean, cold start.)

Any ideas?

Jim

Run a complete Check Disk.

 

[Paul]

Run a complete Check Disk.

Meaning run CHKDSK with individual sector by sector read-verify.

http://www.hard-drive-help.com/image-files/chkdsk.gif

You should not defragment a "damaged" disk. Even a check of the
SMART statistics may warn you of trouble, in which case you wouldn't
try a defrag as your first step. Defrag is only for 100% healthy disks.
If a disk is sick enough, even a CHKDSK may not be the best idea
(i.e. if each operation used by CHKDSK to correct things, causes
more data corruption and lost files - like if a disk drive ribbon
cable is loose).

http://www.hdtune.com/HDTune_Health.gif

HDTune version 2.55 is free.

http://www.hdtune.com/files/hdtune_255.exe

The two statistics I check regularly, are marked in red circles here.
If mine were non-zero, I'd be doing more checks, planning a move off
that disk, and so on. CHKDSK would take a while to run, which is why
I don't run it regularly in sector by sector check mode. Glancing at
the SMART check, only takes a couple seconds of your time (it's not
a thorough check, more of a "I'm not feeling well" kinda check). The
stats in yellow here, have been yellow from the day I bought the drives
(two identical drives report the same way), and are of no concern.

http://img3.imageshack.us/img3/8117/hdtuneok.gif

Paul

 

[jim]

On Sun, 03 Jun 2012 14:13:30 -0400, in

Meaning run CHKDSK with individual sector by sector read-verify.

http://www.hard-drive-help.com/image-files/chkdsk.gif

You should not defragment a "damaged" disk. Even a check of the
SMART statistics may warn you of trouble, in which case you wouldn't
try a defrag as your first step. Defrag is only for 100% healthy disks.
If a disk is sick enough, even a CHKDSK may not be the best idea
(i.e. if each operation used by CHKDSK to correct things, causes
more data corruption and lost files - like if a disk drive ribbon
cable is loose).

http://www.hdtune.com/HDTune_Health.gif

HDTune version 2.55 is free.

http://www.hdtune.com/files/hdtune_255.exe

The two statistics I check regularly, are marked in red circles here.
If mine were non-zero, I'd be doing more checks, planning a move off
that disk, and so on. CHKDSK would take a while to run, which is why
I don't run it regularly in sector by sector check mode. Glancing at
the SMART check, only takes a couple seconds of your time (it's not
a thorough check, more of a "I'm not feeling well" kinda check). The
stats in yellow here, have been yellow from the day I bought the drives
(two identical drives report the same way), and are of no concern.

http://img3.imageshack.us/img3/8117/hdtuneok.gif

Paul

I ran chkdsk /f from the command line which set up a run-once command for
that in the registry and rebooted. No problems encountered.

Secondarily is
http://www.hddstatus.com/hdrepshowreport.php?ReportCode=6125858&ReportVerification=04E34F5C

jim

 

[Paul]

On Sun, 03 Jun 2012 14:13:30 -0400, in


I ran chkdsk /f from the command line which set up a run-once command for
that in the registry and rebooted. No problems encountered.

Secondarily is
http://www.hddstatus.com/hdrepshowreport.php?ReportCode=6125858&ReportVerification=04E34F5C

jim

Good.

Now, we go back and look at your symptoms again.

"At 7AM+ it was still at 23% and FWIW, was still moving the same .tib
backup file of 75meg."

By any chance was this a 75GB file ?

And are you low on free space ? A defragmenter needs free space to work
with, and cannot succeed if the free space is too small.

If you have room, move the 75GB TIB file temporarily to another partition
or storage device, re-run the defragmenter on the partition you were
working on, then move the TIB back. (I hope TIB files have no quirky
characteristics, and they can be moved safely...) While moving the
TIB file back, you could put it in the My Documents tree temporarily,
as System Restore doesn't track file activity in My Documents and
then you won't have fragmentation due to an Explorer file copy
competing with System Restore trying to track the changes. System
Restore in WinXP, tracks changes outside the My Documents tree. And
System Restore (which works on its own), would be running and working
the file system, at the same time you're copying. Once the TIB is copied
back into My Documents, you can move it when done, back to where it belongs.
(And then, even if System Restore were to make some dumb move, there is
only one writer process running on your system instead of two competing
writers.) Doing the return copy that way, might avoid the 75GB file
from being fragmented again. No guarantees.

I have partitions I defragment and partitions I do not defragment.
My largest partitions, hold only data files, including images of
stuff in the multi-GB range. There is no point defragmenting them,
a waste of time, and likely, physically impossible. If I view
a defragmenter report for the partition, the report is "all red",
indicating virtually everything on the partition is fragmented.
But, this is not a performance issue. My OS partition, on the
other hand, is filled with small files, frequently referenced,
and then a "bit of spit and polish" every three months, makes
a slight difference. I did my maintenance run, only a couple
days ago. Example follows.

*******

Note - the following partition was defragmented, *without* a
defragmenter program. (The built-in defragmenter here, was
used to take this picture, but that's all it contributed to the
process.) Takes about 50 minutes for the whole procedure, which
must be attended (done from command line). And the 50 minute
interval is guaranteed (i.e. there is little variance from
one run to the next). I just did this a couple days ago.
System Restore is turned off, which is why it's relatively clean.
Hint: I copy C: to an empty partition, then copy it back
I even manually position the pagefile and hiberfil on the left
LOL.

http://img528.imageshack.us/img528/2626/spitpolish.gif

Paul

 

[jim]

On Sun, 03 Jun 2012 18:21:41 -0400, in

Good.

Now, we go back and look at your symptoms again.

"At 7AM+ it was still at 23% and FWIW, was still moving the same .tib
backup file of 75meg."

By any chance was this a 75GB file ?

It was created a few minutes after I installed the OS on a clean disk,
before anything was done.

~~~~
¦ Local_disk_(C) .tib 3573,674K.a.. 12-26-11 12:00:10
¦ MyBackup2 .tib 430,143K.a.. 7-30-11 9:17:48
¦ backup1 .tib 75590655.a.. 7-19-11 12:43:00
~~~~
(The big K means Kilobytes. backup1.tib is small enough to display the
entire number of bytes and that 75 Megabyte file is the one the defrag
program happened to be on when the process hung. I mentioned it because
of its inconsequential size.)

And are you low on free space ? A defragmenter needs free space to work
with, and cannot succeed if the free space is too small.

~~~~
DISK C:JASAR250SG
Available Bytes
112,988,078,080
~~~~

 

[Paul]

On Sun, 03 Jun 2012 18:21:41 -0400, in


It was created a few minutes after I installed the OS on a clean disk,
before anything was done.

~~~~
¦ Local_disk_(C) .tib 3573,674K.a.. 12-26-11 12:00:10
¦ MyBackup2 .tib 430,143K.a.. 7-30-11 9:17:48
¦ backup1 .tib 75590655.a.. 7-19-11 12:43:00
~~~~
(The big K means Kilobytes. backup1.tib is small enough to display the
entire number of bytes and that 75 Megabyte file is the one the defrag
program happened to be on when the process hung. I mentioned it because
of its inconsequential size.)


~~~~
DISK C:JASAR250SG
Available Bytes
112,988,078,080
~~~~

Is the .tib safe to move ?

And if so, copy the .tib to a second hard drive, change the name to
backup1temp, then copy it back (so it's not stored in the same location
as the original). Then, delete backup1 (empty trash bin),
rename backup1temp to backup1, then try to defrag again.
The idea being, to store it in a slightly different set
of clusters.

Paul

 

[jim]

On Sun, 03 Jun 2012 22:12:51 -0400, in

Is the .tib safe to move ?
Yes


And if so, copy the .tib to a second hard drive, change the name to
backup1temp, then copy it back (so it's not stored in the same location
as the original). Then, delete backup1 (empty trash bin),

Good idea, since it could be a mix of reasons about that file...though
more likely the defrag prog was just on that file when the music stopped.

 

[glee]

On Sun, 03 Jun 2012 22:12:51 -0400, in


Good idea, since it could be a mix of reasons about that file...though
more likely the defrag prog was just on that file when the music
stopped.

TIB files (True Image Backups) often take a very long time to
defragment, and it has been argued that they should NOT be defragmented
at all, because of the great amount of time needed to defragment them,
the risk of corrupting the image when defragging it, and that the
resulting defragmented TIB file won't save you any time when using it
for restore.... so it's a complete waste of time.

Never store an image file of your drive or partition on that drive or
partition. I always keep copies of TIB files on a separate partition
and on a separate drive that are not defragged. Keeping a large unused
image file on you system/boot partition just slows you system down.....
and can make defrag seemingly hang.

If you use a third-party defragger, you can usually exclude file
types.... image files should be excluded from defrag in the defragger's
options.

 

[glee]

On Sun, 03 Jun 2012 22:12:51 -0400, in


Good idea, since it could be a mix of reasons about that file...though
more likely the defrag prog was just on that file when the music
stopped.

PS: Additionally, the drive/partition/volume containing TIB files
should have System Restore and Windows Indexing turned off.... another
reason to keep TIB files off your system/boot drives.

As for the issue of corruption of TIB files and defragmenting:

http://www.dslreports.com/forum/r23...onis-true-image-Home-2010-and-Tuneup-Utilitie

http://windowssecrets.com/forums/showthread.php/132131-acronis-reports-file-corrupt

 

[jim]

On Mon, 4 Jun 2012 08:08:56 -0400, in microsoft.public.windowsxp.general,

TIB files (True Image Backups) often take a very long time to
defragment, and it has been argued that they should NOT be defragmented
at all, because of the great amount of time needed to defragment them,
the risk of corrupting the image when defragging it, and that the
resulting defragmented TIB file won't save you any time when using it
for restore.... so it's a complete waste of time.

Never store an image file of your drive or partition on that drive or
partition. I always keep copies of TIB files on a separate partition
and on a separate drive that are not defragged. Keeping a large unused
image file on you system/boot partition just slows you system down.....
and can make defrag seemingly hang.

If you use a third-party defragger, you can usually exclude file
types.... image files should be excluded from defrag in the defragger's
options.

Now there's an interesting message with good advice.
The .tib files I listed are not the current operating system. At the time
I made them July,July and December,2011, the currently booting C disk was
a system data disk. I made an the Acronis boot disk (tested) that could
lay one of them down as a new OS on a clean disk so long as their location
is on an operating disk -- and operating disk does not necessarily mean
recognized by Windows but more that it will spin up and seek.

jim

 

[jim]

On Mon, 4 Jun 2012 08:15:39 -0400, in microsoft.public.windowsxp.general,

PS: Additionally, the drive/partition/volume containing TIB files
should have System Restore and Windows Indexing turned off.... another
reason to keep TIB files off your system/boot drives.

Thanks.

 

[Paul]

PS: Additionally, the drive/partition/volume containing TIB files
should have System Restore and Windows Indexing turned off.... another
reason to keep TIB files off your system/boot drives.

As for the issue of corruption of TIB files and defragmenting:

http://www.dslreports.com/forum/r23...onis-true-image-Home-2010-and-Tuneup-Utilitie


http://windowssecrets.com/forums/showthread.php/132131-acronis-reports-file-corrupt

I don't have, or use Acronis, but there appears to be a "validate" capability.
Perhaps the files could be validated to make sure they're still good.

http://forum.acronis.com/forum/20240

I also haven't been able to find any third party tool to read the format
as such. There is a converter for VMWare, but that changes to something
VMWare can use. I'd hoped there would be something that could just
mount the thing (like 7ZIP does for many formats). But don't see anything
general purpose like that.

If the .tib files have some special properties, you'd think Acronis could
provide warnings not to move them etc. (Like, sparse file, alternate streams
or whatever.) A good backup format, you should at least be able to move
to other media, otherwise it would be pretty useless.

Paul

 

[glee]

I don't have, or use Acronis, but there appears to be a "validate"
capability.
Perhaps the files could be validated to make sure they're still good.

http://forum.acronis.com/forum/20240

I also haven't been able to find any third party tool to read the
format
as such. There is a converter for VMWare, but that changes to
something
VMWare can use. I'd hoped there would be something that could just
mount the thing (like 7ZIP does for many formats). But don't see
anything
general purpose like that.

If the .tib files have some special properties, you'd think Acronis
could
provide warnings not to move them etc. (Like, sparse file, alternate
streams
or whatever.) A good backup format, you should at least be able to
move
to other media, otherwise it would be pretty useless.

The best practice with Acronis TI and probably other imaging programs,
is to make your backup on the media where you want to store it. I
alternately make images in two different locations. I'm not sure I see
the point of *moving* an image after making it, but yes, it should be
something that can be done. Acronis TI will allow moving, but
validating the file after the move is recommended. The statement at the
one link not to move them is not something Acronis agrees with. Acronis
also says defragging risks are no greater than with any file, but others
cite evidence to the contrary. It's not written in stone, but it's a
risk.

Imaging is not a backup format... imaging tools are not backup programs.
There is a difference.