On 2016-02-08 13:42:47 [+0100], Enrico Zini wrote:
> Hello,
Hi,
> I was archiving and xz-compressing mail from last year when my laptop
> tripped thermal protection and switched off. The resulting filesystem
> situation is this:
…
> The source files are gone, and the target files are empty.
>
> I have not checked xz's sources, but this looks like the result of a
> missing fdatasync on the target file before the source has been removed.
First all, I'm sorry for your loss. I've been looking at this a few
years ago and then somehow forgot about it. Now I kinda remembered.
I *think* the problem (was/is) that
write()
close()
unlink()
ended up with commited metadata but not data so you see the file but
data did not hit the disk (completely). That probably was the time
before ext4 changed its default behaviour with a few hacks once user
reported that KDE lost all its configurations files because there were
rewritten at boot time.
A fdatasync() would probably avoid that[0]. Should we really try to do
that? If so, we should also go after gzip, bzip2, … and make the change
there, too. They don't do that (behave like xz does) but I think if we
make such a change we should behave consistenly across those tools.
In theory we might have worse performance due to that sync but this
shouldn't hit most users. I think most ppl use xz via a pipe (say
`tar J') so they won't be affected by that sync. We probably could also
avoid that sync together with the `--keep' option. And then we would be
able to catch errors before close() and unlink of the original.
[0] I would check if linux's fs ppl if we really consider it.
> Enrico
Sebastian
