Filesystem start runs fsck on ext4 filesystem
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cluster-agents (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Maverick |
Won't Fix
|
Medium
|
Unassigned | ||
heartbeat (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Maverick |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: heartbeat-common
Package heartbeat-common 2.99.2+
The script
/usr/
contains a list of filesystem types for which fsck is not run. This list does not include ext4, although it does include ext3.
=======
SRU Justification
IMPACT:
This bug affects users running DRBD clusters with ext4 filesystem on top. Every time that a cluster node tries to perform a takeover on a DRBD resource with ext4 filesystem, it will run fsck, which can cause the takeover to take much longer than expected. In Clustered scenarios, this might affect the availability. For this reason, some filesystems avoid this step, including ext3. Unfortunately, ext4 is not yet listed in the version for Maverick.
REPRODUCE:
1. Install a two node DRBD cluster with Pacemaker. Format the DRBD block device with ext4.
2. Once they are configured and running in Master/Slave, perform a hard takeover by switching off the Master node.
3. In the Slave node, check syslog, where the following output will appear:
lrmd: [2623]: info: RA output: (res_fs:
HOW FIXED:
The fix is simple, and consists on adding ext4|ext4dev to the list of filesystems for which to avoid performing fsck. This has been fixed upstream (and in Natty) and it is the same approach.
PATCH:
Attached. Uploaded to maverick-proposed for review there.
REGRESSION POTENTIAL:
Minimal. I've tested this thoroughly.
=======
Related branches
Changed in heartbeat (Ubuntu): | |
status: | New → Invalid |
Any updates on this bug ?