[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #46193] Discussion of system crash behaviours

From: Yanyan Jiang
Subject: [bug #46193] Discussion of system crash behaviours
Date: Tue, 13 Oct 2015 02:25:57 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/601.1.56 (KHTML, like Gecko) Version/9.0 Safari/601.1.56


                 Summary: Discussion of system crash behaviours
                 Project: make
            Submitted by: jiangyy
            Submitted on: Tue 13 Oct 2015 02:25:56 AM GMT
                Severity: 3 - Normal
              Item Group: Documentation
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: None
        Operating System: Any
           Fixed Release: None
           Triage Status: None



I am currently working on the file system reliability issues. I have a disk
driver that is able to simulate crash disk sites after injected power failures
(inspired by two OSDI'14 papers about crash sites, and they found interesting
bugs in many production systems like database). This disk is compatible with
the Linux block driver semantics (refer to 
and may create many crash sites that pending blocks are partially flushed into
the disk.

Our tool finds that a typical compiler (e.g., gcc) may suffer the issue of
crash inconsistency. Specifically, there is a chance that for the binary
output file (e.g., a .o file):

1. its timestamp is updated and gmake considers this file is up-to-date.
2. its actual data is not persisted to the disk.

On an ext4 filesystem (default setting) of a typical Linux distribution, we
observed that there is a chance of leaving a 0-byte output file whose
timestamp is updated. In more relaxed settings (e.g., old-time filesystems), a
system crash would leave partially corrupted file in the filesystem with
timestamp updated (e.g., several blocks are missing but with a correct

Note that this is NOT a defect for gcc or gmake as they have nothing to do
with the crash semantics. However, if the user continues the incremental build
after system crash, the entire thing would proceed, gmake will consider the
generated .o file is up-to-date and proceed into the next stages, finally
leading to incorrect outputs.

Though it is not a software defect, and is expected to be very rarely in
practice. Neverthless, gmake is supposed to be general and to run on any
platform. I am wondering if we should make users aware of this phenomenon
(e.g., adding a small section in the document to discuss this issue).


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]