> Theo de Raadt wrote:
> > How does sync() fix this? Please explain this. Look at the source
> > code.
> > sync() is an asyncronous call requesting syncronization, and once
> > it has marked the blocks that should be pushed, it returns before
> > the work has been done.
> Ah, indeed.
> > > 2. cp could do an fsync call. There was a thread about this a while ago?
> > How does fsync fix this? What if it returns an error. What do you do next.
> > Should cp spin until fsync returns non-error, or what should it do.
> Exit with an error? Same as if it got EIO or ENOSPC from a write? Then the
> command chain will stop before the mv.
The OP demonstrated a problem. Any solution presented should try to fix
the problem, not just "maybe".
> Even after many tries, I have not yet been able to corrupt the
> filesystem so fsck cannot repair it without manual intervention.
Another less severe corner fail case I have found is that on a couple of buggy
386 laptops (that will be replaced soon anyway) with temperamental over temp
shutdowns on some bootups (and now failing host controller, I'm guessing due to
age/damage). I have found LOST+FOUND can fill up the filesystem, preventing
library and kernel randomisation from taking affect. I have a script to check
and remove older LOST+FOUND files. It's unlikely that there would be anything
important lost on these browsing machines anyway.
I have few questions, why are soft updates not on by default, and
does they help consistency in case of failure, are they recom‐
mended to be turned on only in specific case ? Except my mis‐
take, they help keeping drive consistent, avoid the need for fsck
for most hard failure cases, and only risk to have unused spare
sectores which can be later recovered.
Would not they help with the file system in general or some draw
back with their use ?