Sysinstall automatic filesystem size generation.

[Mark Kirkwood]

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