XFS leaves garbage in file if app does write-new-then-rename without f(data)sync
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux-source-2.6.15 (Ubuntu) |
Won't Fix
|
Medium
|
Unassigned |
Bug Description
update-
XFS commits metadata (the rename) to disk before data (the file contents) so that an unfortunately-timed crash leaves the file containing garbage (ie whatever those disk blocks happened to contain before).
Either XFS needs to not do this, or all programs that use the above-described technique to update files (practically all of them) have to be changed to call f(data)sync at an appropriate point - otherwise there is a risk that those programs will break later because their data files contain nonsense. Note that the latter change would probably significantly slow down installation and upgrade as well as other functions and would involve the editing of many applications.
Changed in dpkg: | |
status: | Unconfirmed → Confirmed |
description: | updated |
setting to critical as corruption prevents a lot of packages from upgrading and there is no obvious way to fix said corruption.