Sysinstall automatic filesystem size generation.

[Don Lewis]

On 30 Aug, Matthias Buelow wrote:
> Jon Dama wrote:
> 
>>Ironically, phk backed out the underlying support for this safety fix
>> from the FreeBSD kernel b.c. it wasn't integrated into the softupdates
>>code
>>whereas in reality the proper course of action would have been to hook it
>>in.  :-/
> 
> Can it be put into softupdates at all? From what I understand (which
> is probably a rather sketchy idea of the matter), write barriers
> work because they are only used here to separate journal writes
> from data writes (i.e., to make sure the log is written, by flushing
> the cache, before any filesystem data hits the platters). I've read
> the softupdates paper some time ago and haven't found similar
> sequence points where one could insert such flushing.  One would
> have to "flush" all the time, either continuously or in very short
> intervals, in order to keep the ordering, which then would amount
> to the same effects as if one simply disabled the cache. But probably
> I'm wrong here (I hope).

Performance might be bad, but it is still likely to be better than
totally disabling write caching.  For instance if you had two different
write transaction pairs, where write B depends on write A, and write D
depends on write C, you could issue writes A and C, flush the drive's
write cache, and then issue writes B and D.  You could also optimize
large sequential writes by writing all the data blocks, flushing the
write cache, and then updating the inode and bitmap blocks.  Grouping
writes to minimize the number of flushes might help performance.

The key is that the drive's write cache needs to be flushed before doing
a write that depends on an earlier write.  The complication is that
softupdates tosses the information about a write as soon as the drive
acknowledges it, but if write caching is enabled, softupdates would need
to retain this information until the drive's write cache is flushed.

I think you could still get file system corruption on power failure if
you are using ATA drives, because most high capacity drives write a
track at a time, in many cases re-writing data that was last touched in
the distant past.  If the power fails part way through a track rewrite,
then the old data on that track may be lost.