Sysinstall automatic filesystem size generation.

[Don Lewis]

On 29 Aug, Matthias Buelow wrote:
> Don Lewis wrote:
> 
>>> I'd like to stress the "probably". I've already seen unrepairable
>>> filesystem corruption with softupdates enabled in the past with
>>> "good" scsi disks at power loss.
>>
>>Did you remember to disable write caching by setting the WCE mode page
>>bit to zero?  At least with SCSI, it doesn't seem to affect performance
>>under most workloads.
> 
> No.. I thought that with SCSI it is "ok" to leave the cache enabled
> because SCSI supports some sort of request queueing which doesn't
> break the order established by softupdates?

If WCE is set to 1, the drive immediately acknowledges writes.  If WCE
is set to 0 and the OS is doing tagged command queuing, the drive won't
tell the OS that the write is complete until the data hits the platter,
but a typical drive could have up to about 64 outstanding writes (or
some combination of reads and writes) that it is free to re-order as it
sees fit in order to increase performance.

The key is that WCE must be set to 0 so that softupdates knows when
each of the writes that it has queued to the drive has completed so that
softupdates doesn't queue up any writes that depend on the previously
queued writes before those older writes have reached stable storage. If
WCE is set to 1, the dependent writes could reach the platter too early
and the earlier writes that the later writes depend on could be lost
from the drive's cache because of a power failure, which would put the
file system into an inconsistent state.


>>I've seen this when doing compile, run, panic experiments.  The
>>executable that I just compiled would end up with a size of zero after
>>the reboot because it was still cached in RAM and executing from RAM
>>when the machine paniced.  The executable was scheduled to be written to
>>disk about 30 seconds after it was compiled and linked, but the machine
>>paniced before the 30 seconds was up.
> 
> Yes, that would account for the 0-size files but not for ones that
> got deleted by background fsck, with it logging "UNREF FILE" messages
> (and that were files that have definitely NOT had directory entries
> removed since amongst those were dot-files in my homedir, which I
> had to restore from backup then, and some others where I have not
> yet found out which they were..)

I believe I've seen UNREF'ed files, but they always seem to be compiler
temporaries, etc.  I've never lost any files that I haven't recently
touched.