Sysinstall automatic filesystem size generation.
markir at paradise.net.nz
Tue Aug 30 02:23:39 GMT 2005
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...
> 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).
More information about the freebsd-stable