Power failure during Windows 7 defrag (x64 Ultimate edition)

Hi all,

Yesterday night, my Windows 7 started a disk defragmentation (Windows
7 defaultly scheduled a disk defrag once a week).
Unfortunately, the Murphy's law was verified once again : the defrag
started at 1:00 AM and my house had a general power failure at 1:10 AM
in the middle of the C:\ defrag.

Hopefully, I was able to reboot.
I planned a CHKDSK from Windows 7 which successfully executed (upon
next reboot).
I did not find yet how to get the report (generated at boot time) but
I read that I could get it from the Event Viewer in a Wininit event.
Anyway, my system reboot fine and I do not notice any instability.

* Is the CHKDSK execution enough ? Is there anything more that I
should do ?
* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?

Thanks in advance.

On 03/08/11 16:42, Castor Nageur wrote:
Hi all,

Yesterday night, my Windows 7 started a disk defragmentation (Windows
7 defaultly scheduled a disk defrag once a week).

Defragging is almost always close to useless, and is certainly not worth
doing once a week. Just because it is a Windows default, does not mean
it makes sense.

Unfortunately, the Murphy's law was verified once again : the defrag
started at 1:00 AM and my house had a general power failure at 1:10 AM
in the middle of the C:\ defrag.

Hopefully, I was able to reboot.
I planned a CHKDSK from Windows 7 which successfully executed (upon
next reboot).
I did not find yet how to get the report (generated at boot time) but
I read that I could get it from the Event Viewer in a Wininit event.
Anyway, my system reboot fine and I do not notice any instability.

* Is the CHKDSK execution enough ? Is there anything more that I
should do ?

No, the defragmentation is pretty safe. It is not always /entirely/
safe in the event of a power failure or crash - no operation on the disk
is. But if chkdsk is happy, your filesystem is at least consistent.
There is perhaps a small chance that some data in a file has been
damaged, but it's unlikely. Don't worry about it.

* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?


It is not true - you certainly /can/ get corruption on NTFS from crashes
or power failures, but they don't happen often. NTFS has metadata
journalling, and is reasonably robust - corruptions are rare, but only
an MS sycophant would claim they /cannot/ happen. The same journalling
is used during defrag, and gives the same protection.

There is also always a small chance of a more physical or electrical
problem with a disk during power failures, especially if there is a
period with poor-quality power (power that comes and goes, single-phase
failures, etc.).

But in general, if you don't see any problems, be happy.


Thanks in advance.

Castor Nageur wrote:
Hi all,

Yesterday night, my Windows 7 started a disk defragmentation (Windows
7 defaultly scheduled a disk defrag once a week).
Unfortunately, the Murphy's law was verified once again : the defrag
started at 1:00 AM and my house had a general power failure at 1:10 AM
in the middle of the C:\ defrag.

Hopefully, I was able to reboot.
I planned a CHKDSK from Windows 7 which successfully executed (upon
next reboot).
I did not find yet how to get the report (generated at boot time) but
I read that I could get it from the Event Viewer in a Wininit event.
Anyway, my system reboot fine and I do not notice any instability.

* Is the CHKDSK execution enough ? Is there anything more that I
should do ?

I don't think so.

* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?

Very likely untrue, as that would require a perfect implementation
and a reliable flush-to-disk. In particular the second is not
done on consumer grade disks, as the Linux kernel folks
found out when they decided to not trust the specification but
actually try it out. As it turns typical consumer disks can
return from a write with disk-buffer flush _before_ the data is
on disk. This is an exceedingly stupid thing to do by the HDD
manufacturers, but hardly the first time they messed up.

The most important practical consequence is that for reliable
database commits you either have to use HDDs with buffer
turned off (very slow, may be acceptable if you just put the
DB journal on it), working flush (SCSI or SAS may have this
as one of the very few advantages) or an UPS with orderly
shut-down in case of power fail and generous waiting times
before power is withdrawn from the disks after the flush
command (should be standard on modern OSes).

As to a perfect implementation, Microsoft is unlikely to have
achieved that.

That said, it typically works nonetheless, as in 99% or so of the
time. Unlike FAT, NTFS is a lot harder to mess up. If CHKDSK does
not complain you should be fine.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

On 08/03/2011 10:40 AM, Arno wrote:
Castor wrote:
Hi all,

Yesterday night, my Windows 7 started a disk defragmentation (Windows
7 defaultly scheduled a disk defrag once a week).
Unfortunately, the Murphy's law was verified once again : the defrag
started at 1:00 AM and my house had a general power failure at 1:10 AM
in the middle of the C:\ defrag.

Hopefully, I was able to reboot.
I planned a CHKDSK from Windows 7 which successfully executed (upon
next reboot).
I did not find yet how to get the report (generated at boot time) but
I read that I could get it from the Event Viewer in a Wininit event.
Anyway, my system reboot fine and I do not notice any instability.

* Is the CHKDSK execution enough ? Is there anything more that I
should do ?

I don't think so.

* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?

Very likely untrue, as that would require a perfect implementation
and a reliable flush-to-disk. In particular the second is not
done on consumer grade disks, as the Linux kernel folks
found out when they decided to not trust the specification but
actually try it out. As it turns typical consumer disks can
return from a write with disk-buffer flush _before_ the data is
on disk. This is an exceedingly stupid thing to do by the HDD
manufacturers, but hardly the first time they messed up.

The most important practical consequence is that for reliable
database commits you either have to use HDDs with buffer
turned off (very slow, may be acceptable if you just put the
DB journal on it), working flush (SCSI or SAS may have this
as one of the very few advantages) or an UPS with orderly
shut-down in case of power fail and generous waiting times
before power is withdrawn from the disks after the flush
command (should be standard on modern OSes).

As to a perfect implementation, Microsoft is unlikely to have
achieved that.

That said, it typically works nonetheless, as in 99% or so of the
time. Unlike FAT, NTFS is a lot harder to mess up. If CHKDSK does
not complain you should be fine.

Arno

My understanding is that ZFS is pretty robust, even on somewhat shoddy
disks.

Defragging is almost always close to useless, and is certainly not worth
doing once a week. Just because it is a Windows default, does not mean
it makes sense.

My experience is the opposite. An NTFS computer will be noticeably
slower after some months.
--
Ed Light

Better World News TV Channel:
http://realnews.com

Iraq Veterans Against the War and Related:
http://ivaw.org
http://couragetoresist.org
http://antiwar.com

Send spam to the FTC at

Thanks, robots.

On 03/08/2011 10:42 AM, Castor Nageur wrote:
* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?

Thanks in advance.

Yeah, NTFS is a journalled filesystem, the defrag process would just get
replayed back to it's most recent write operation. Nothing gets erased
until it is overwritten. Data will remain in its original location until
then.

Yousuf Khan

Ed Light wrote

Defragging is almost always close to useless, and is certainly not
worth doing once a week. Just because it is a Windows default, does
not mean it makes sense.

My experience is the opposite.

Like hell it is.

An NTFS computer will be noticeably slower after some months.

Pity a defrag makes no difference and you couldnt pick that in a randomised double
blind trial with you not being allowed to run a ute that displays fragmentation.

And the reason for that is that **** all that most do on their desktop systems
are affected at all by the very fast seek between fragments on modern systems
and most stuff like playing media files isnt affected at all and thats about the
only linear processing of large files most ever do on modern desktop systems.

On 04/08/11 00:33, Ed Light wrote:

Defragging is almost always close to useless, and is certainly not worth
doing once a week. Just because it is a Windows default, does not mean
it makes sense.

My experience is the opposite. An NTFS computer will be noticeably
slower after some months.

Well, an NTFS computer is by definition a Windows computer, so this
should not come as a big surprise!

Seriously, defragging makes little difference for most real-world usage.
There are exceptions, and some types of uses where fragmentation can
have a noticeable effect - but those are rare. If you think your system
is slow because of fragmentation, then there will be other things (a
faster disk, more memory, or a different approach to the task in hand)
that will make a far bigger difference. Rod might not have been at his
most polite in his reply, but he is correct.

On 03/08/11 23:57, cjt wrote:
On 08/03/2011 10:40 AM, Arno wrote:
Castor wrote:
Hi all,

Yesterday night, my Windows 7 started a disk defragmentation (Windows
7 defaultly scheduled a disk defrag once a week).
Unfortunately, the Murphy's law was verified once again : the defrag
started at 1:00 AM and my house had a general power failure at 1:10 AM
in the middle of the C:\ defrag.

Hopefully, I was able to reboot.
I planned a CHKDSK from Windows 7 which successfully executed (upon
next reboot).
I did not find yet how to get the report (generated at boot time) but
I read that I could get it from the Event Viewer in a Wininit event.
Anyway, my system reboot fine and I do not notice any instability.

* Is the CHKDSK execution enough ? Is there anything more that I
should do ?

I don't think so.

* I read that NTFS based file systems could not be corrupted even if a
crash or power failure occurred in the middle of a defrag process or
any write operation ? Is it true ?

Very likely untrue, as that would require a perfect implementation
and a reliable flush-to-disk. In particular the second is not
done on consumer grade disks, as the Linux kernel folks
found out when they decided to not trust the specification but
actually try it out. As it turns typical consumer disks can
return from a write with disk-buffer flush _before_ the data is
on disk. This is an exceedingly stupid thing to do by the HDD
manufacturers, but hardly the first time they messed up.

The most important practical consequence is that for reliable
database commits you either have to use HDDs with buffer
turned off (very slow, may be acceptable if you just put the
DB journal on it), working flush (SCSI or SAS may have this
as one of the very few advantages) or an UPS with orderly
shut-down in case of power fail and generous waiting times
before power is withdrawn from the disks after the flush
command (should be standard on modern OSes).

As to a perfect implementation, Microsoft is unlikely to have
achieved that.

That said, it typically works nonetheless, as in 99% or so of the
time. Unlike FAT, NTFS is a lot harder to mess up. If CHKDSK does
not complain you should be fine.

Arno

My understanding is that ZFS is pretty robust, even on somewhat shoddy
disks.

Many systems are pretty robust, even in the face of not-quite-honest
hard disks and enabled disk write buffers. NTFS is not bad, and a world
ahead of FAT. ZFS has a reputation of being very solid, as you say.
But so also are most major Linux filesystems - ext3, ext4, xfs and jfs
(and newcomer btrfs). Ironically, xfs is viewed as being /less/ robust
on power failure, even though it is at least as good as the others -
this comes from misunderstandings of the safest combinations of write
buffers, barriers, etc., along with the xfs documentation which explains
the problems that other filesystems mostly gloss over. While NTFS
documentation implies that metafile journalling makes it safe, xfs
documentation goes to lengths to explain how it is still unsafe, and how
you can improve it.

The best advice is to start out with the most appropriate filesystem for
your system (NTFS for windows, typically ext4 or xfs for Linux, and ZFS
for Solaris) depending on your requirements). Then read the advice in
the filesystem documentation. Sometimes you have to choose a balance
between performance issues and robustness in the face of crashes or
power outage - that's /your/ choice.

If you need solid reliability during power fails, get an UPS so that
your system can shut down cleanly. /No/ filesystem will be entirely
reliable without that.

On 8/4/2011 6:34 AM, David Brown wrote:

Rod might not have been at his
most polite in his reply, but he is correct.
Most of us have him filtered out.

--
Ed Light

Better World News TV Channel:
http://realnews.com

Iraq Veterans Against the War and Related:
http://ivaw.org
http://couragetoresist.org
http://antiwar.com

Send spam to the FTC at

Thanks, robots.