Matthias Buelow wrote:
From what I understand from googling around on that issue, the
write-barrier stuff should make that much more unlikely. Of course
there could be the situation that it was a kernel that did not
(properly) support write-barriers yet, or the Linux implementation
has/had bugs (not too unlikely), or the disk was so broken that
even the flushing workaround strategies were ignored or it otherwise
didn't properly flush it, etc. But they're at least trying to cope
with the issue. BTW., when have you last seen a broken NTFS?
LOL, well quite often - nt4 seemed to specialize in this, win2k and
winxp (particularly 2k) however, seem much better...
While
I don't do Windows much, I have had quite a few crashes on Windows
(2000, XP) over the years on various machines, and I always asked
myself how it could be that the system is up almost immediately
(probably due to log replay) with no discernible filesystem damage.
Windows (NT) has been doing the write barrier flush tricks (disabling-/
reenabling the cache for flushing it) for longer than Linux and I
would think that this contributes to the fault resilience of NTFS.
Not that I would imply that NTFS can't be corrupted, of course.
But otherwise, thanks for a very informative post.
Hmm, I think OSX does something like this too.
Funnily enough, I have never lost files while using FreeBSD, even tho
I'm using ATA disks with the write cache enabled - and I have had power
loss situations. The robustness was one of the things that persuaded me
to switch from (Redhat 7.3/8.0 I think) to FreeBSD (4.6 I think).
However that is ancient history, If everyone is working out how to
manipulate the write cache on-demand, then I guess FreeBSD needs to as
well...(not volunteering... probably a bit out of my league).
Cheers
Mark
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
