Hi, Gzip version: 1.6
I am developing a tool to validate crash safety of application software. I have just found that the file deletion has a potential safety venerability: if only a prefix of I/O operations are flushed to disk, after reboot, the file-system would only contain a 0-byte file (old file is deleted while the data is not reached to disk yet). A paper FYI: http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/17780-osdi14-paper-pillai.pdf <http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/17780-osdi14-paper-pillai.pdf> (Table 1 on Page 440). Data append can be (virtually) reordered with any operation at default ext3 and ext4 settings. I recommend to use fsync() to persist the .gz file before deletion. — strace log — 36 open("a", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = 3 37 fstat64(3, {st_mode=S_IFREG|0664, st_size=19730, ...}) = 0 38 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM XCPU XFSZ], [], 8) = 0 39 open("a.gz", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4 40 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 41 read(3, "10017649652034232324895361757801"..., 65536) = 19730 42 read(3, "", 45806) = 0 43 write(4, "\37\213\10\10\24\312\312V\0\3a\0-\334m\226\234\274\22\3\340\377Y\r \30l\354\375o,z\324"..., 9954) = 9954 44 close(3) = 0 45 utimensat(4, NULL, {{1456130580, 76955623}, {1456130580, 128955620}}, 0) = 0 46 fchown32(4, 1000, 1000) = 0 47 fchmod(4, 0664) = 0 48 close(4) = 0 49 rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM XCPU XFSZ], [], 8) = 0 50 unlink("a") = 0 Thank you for your attention! Regards, Yanyan Jiang 蒋炎岩 Institute of Computer Software, Dept. of Computer Science, Nanjing University
