UFS not handling errors correctly

[Kris Kennaway]

Peter Schuller wrote:
>> bg fsck cannot fix arbitrary filesystem corruption.  Nor is it intended to.
> 
> But is not the proposed problem that UFS caused the corruption to
> begin with?

No, "something unexpected happened".

> Given that updates are already done in such a way as to cause
> predictable inconsistency in the event of a crash, should not
> appropriate course of action in a case such as this be to panic,
> unmount the fs, rollback and error out, or otherwise abort the
> operation in a way the filesystem can be fsck:ed and re-mounted
> (assuming the device is alive), rather than cause corruption?

Soft updates isn't journalling, so you can't "roll back" an error.  It 
works by maintaining knowledge of the on-disk state of data and ensuring 
  that it only writes to disk in a suitable order so that the on-disk 
state is supposed to remain consistent.

Unfortunately there are many ways in which this can fail, mostly 
involving external factors violating the assumptions upon which soft 
updates relies.  For example, the data written on disk may not 
correspond to the data dispatched by soft updates, due to things like 
write caching in the hardware, write reordering, data corruption, 
unpredictable disk behaviour during power loss, hardware failure, etc.

Similarly, background fsck assumes that the only filesystem errors it 
will encounter are those permitted by the soft updates model, which are 
"benign", i.e. non-fatal and correctable at runtime.  When the state of 
your disk departs from the realm of these assumptions, bg fsck may not 
be able to repair the damage.

Kris