bugmake - Bugs: bug #46193, Discussion of system crash...

 
 

bug #46193: Discussion of system crash behaviours

Submitted by:  Yanyan Jiang <jiangyy>
Submitted on:  Tue Oct 13 02:25:56 2015  
 
Severity: 3 - NormalItem Group: Documentation
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: NoneOperating System: Any
Fixed Release: NoneTriage Status: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun Oct 18 17:30:18 2015, comment #2:

Please see also bug 46242: make can leave behind out of date files even if nothing crashes.

Egmont Koblinger <egmont>
Tue Oct 13 22:28:57 2015, comment #1:

Fail-stops aren't limited to crashes. Ctrl-Z and network splits sometimes stop make from removing a half-written target. At this shop, we aim to write rules that only write into temporary files, renaming them to the desired name once writing has completed successfully. This also saves us from persistent breakage when multiple builds accidentally contend. Perhaps someone has a write-up linked to from http://make.mad-scientist.net/#resources of how to do this without duplication.

Martin Dorey <mdorey>
Tue Oct 13 02:25:56 2015, original submission:

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 https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt), 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 header).

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).

Yanyan Jiang <jiangyy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by egmont (Posted a comment)
  • -unavailable- added by egmont
  • -unavailable- added by mdorey (Posted a comment)
  • -unavailable- added by jiangyy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Oct 18 17:30:18 2015egmontCarbon-Copy-=>Added egmont

    Back to the top


    Powered by Savane 3.1-cleanup1