pm-utils overrides custom "commit=100" fstab mount option with "commit=0"

[Alex Shtof]

I changed my /etc/fstab to tune the performance of the root file-system. Here is the relevant line from /etc/fstab:

UUID=f51aa298-9ce4-4a19-a323-10df333f34f5 / ext4 data=writeback,noatime,barrier=0,errors=remount-ro,commit=100,nobh,nouser_xattr 0 1

However, when the system boots and I type "mount" I get the following output:
/dev/sda1 on / type ext4 (rw,noatime,data=writeback,barrier=0,errors=remount-ro,commit=100,nobh,nouser_xattr,commit=0)
Notice the "commit=0" at the end.

Googling the problem led me to a work-around - editing the "/usr/lib/pm-utils/power.d/journal-commit" file and changing the line:
JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-0}
to be:
JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-100}

I would expect pm-utils to check for any existing flags in fstab that conflict with the settings it wishes to set, and do not override them.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: pm-utils 1.4.1-3ubuntu1 [modified: usr/lib/pm-utils/power.d/journal-commit]
ProcVersionSignature: Ubuntu 2.6.35-30.54-generic-pae 2.6.35.13
Uname: Linux 2.6.35-30-generic-pae i686
NonfreeKernelModules: nvidia wl
Architecture: i386
Date: Sun Jul 24 22:12:31 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: pm-utils

[osamu (osamu)]

I do not think this is bug in program.

You may call this script as hard to read script with less than sufficient documentation.

Solution is to create a file in /etc/pm/config.d/SET_JOURNAL_COMMIT_TIME_AC with its content:

<pre>
JOURNAL_COMMIT_TIME_AC=100
</pre>

Then it works :-) <email address hidden>

[Martin Stjernholm (msub)]

The problems with this script are wider than that, and it is broken in several aspects. It runs at startup after other mount events and may clobber the mounts present then.

My case is as follows: I need a read-only bind mount. Since bind mounts cannot be given options right away, I have a line in fstab that fixes a basic (r/w) bind mount, and then I have an upstart script which remounts that mount read-only. Now, after that script this little joker comes along and does "mount -o remount,commit=0", which loses the ro flag again.

There are several issues here:

1. The script is not careful to retain the other mount flags when it does its thing. Note that it cannot just reissue the mount flags in fstab - it has to check the currently active flags and ensure that everything except this "commit" setting remains untouched.

2. The script messes with bind mounts. I'm not certain, but I suspect the commit setting only is applicable for real file system mounts.

3. The script runs on startup even when it has no business to mess around at all. In my case it's a desktop computer always connected to A/C. I would expect to be able to set whatever mount options I please in fstab, and not get them clobbered by something elsewhere for a case that is not at all relevant. It should be more careful to do this kind of thing only when switches between A/C and battery actually take place.

4. The script does not give the opportunity to tune the commit timeouts on a per-mount basis.

The proper way to go about this functionality would be to split the commit setting into "commit_on_ac" and "commit_on_battery", so that both can be controlled from fstab or at the appropriate mount places, where ever they may be. But that's of course an entirely different cup of tea than this crude hack. Anyway, fixing items (1) and (3) above would go a long way in isolating its actions to the exact points where they are supposedly beneficiary.