Risk of filesystem corruption with ext3 in lucid

Bug #1097042 reported by lemonsqueeze
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Medium
Unassigned

Bug Description

On my system, a default ext3 mount (no fstab entry) results in:
$ cat /proc/mounts
/dev/sda6 /media/space ext3 rw,nosuid,nodev,relatime,errors=continue,user_xattr,acl,data=ordered 0 0

We can see the "barrier=1" option is missing by default, which can cause severe filesystem corruption in case of power failure (i've been hit recently). Quoting mount(1):

"barrier=0 / barrier=1
This enables/disables barriers. barrier=0 disables it, barrier=1 enables it. Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. The ext3 filesystem does not enable write barriers by default. Be sure to enable barriers unless your disks are battery-backed one way or another. Otherwise you risk filesystem corruption in case of power failure."

the issue is fixed in later kernels (precise 3.2.0-35 is not affected), but lucid users are left to suffer the consequences of this horrifying default.

$ uname -a
Linux netbook 2.6.32-45-generic #101-Ubuntu SMP Mon Dec 3 15:41:13 UTC 2012 i686 GNU/Linux

Revision history for this message
lemonsqueeze (lemonsqueeze) wrote :
information type: Private Security → Public
description: updated
Revision history for this message
lemonsqueeze (lemonsqueeze) wrote :

/etc/fstab can be used as temporary workaround to force barrier=1 :

$ sudo umount /media/space
$ sudo mkdir /media/space
and add an entry to /etc/fstab like:
/dev/sda6 /media/space ext3 barrier=1,rw,nosuid,nodev,uhelper=udisks 0 0

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1097042

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
lemonsqueeze (lemonsqueeze) wrote :

attached log files manually, apport-collect isn't working for some reason...

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
description: updated
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
lemonsqueeze (lemonsqueeze) wrote :

Discussion and some background info in Question #218447.

summary: - by default ext3 is mounted without barrier=1 in lucid
+ Risk of filesystem corruption with ext3 in lucid
Revision history for this message
A. Denton (aquina) wrote :

Yes, but it's not in hardy server which is supported until April 2013 AFAIK.

Revision history for this message
penalvch (penalvch) wrote :

lenosqueeze, thank you for reporting this and helping make Ubuntu better. Lucid reached EOL on May 9, 2013.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the mainline kernels archive directory daily folder. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

tags: added: needs-kernel-logs needs-upstream-testing regression-potential
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.