GNU bug report logs - #22768
Crash safety

Previous Next

Full log

View this message in rfc822 format

From: Antonio Diaz Diaz <antonio <at> gnu.org>
To: 22768 <at> debbugs.gnu.org
Cc: Yanyan Jiang <jiangyy <at> outlook.com>
Subject: bug#22768: Crash safety
Date: Tue, 01 Mar 2016 19:13:15 +0100

Paul Eggert wrote:
>> I know, but how can you guarantee that 'gzip --synchronous' will work 
>> on a system where the 'sync' above does not even guarantee that 
>> 'file.gz' is written to disk before 'file' is deleted?
> 
> Yes, I can guarantee that 'gzip --synchronous' will not lose data on any 
> system conforming to POSIX with the Synchronized Input and Output 
> option.

Unless someone has somehow disabled fsync, I guess. :-)

I am not questioning you. You know very well what you do. It is simply 
that I find the situation so chaotic that I think maybe better methods 
to ensure data permanence have yet to be developed.


> Still, there are people who take these things seriously, and who use
> file systems that are safe in the presence of crashes, and for these
> people grep --synchronous should work.

What I ask myself is, are those people better served by adding 
--synchronous options to every tool, or by using a crash-tolerant file 
system[1]?

"At the ACM Symposium on Operating Systems Principles in October, MIT 
researchers will present the first file system that is mathematically 
guaranteed not to lose track of data during crashes."

[1] http://news.mit.edu/2015/crash-tolerant-data-storage-0824


>> As you said, gzip has run unsafely for decades without a failure. 
> 
> I did not say that!

Sorry, I meant "without a reported failure".

My point is that if gzip has run unsafely for decades without a reported 
failure, maybe all those who take these things seriously are already 
using file systems safe enough to guarantee that well behaved tools like 
gzip do not lose data.


Best regards,
Antonio.

(No need to CC me. I am subscribed to bug-gzip).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.