Here is the relevant line from my /etc/fstab file:

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

Here is what happens when I type the command "mount":

/dev/sda1 on / type ext4 (rw,noatime,data=writeback,barrier=0,errors=remount-ro,commit=100,nobh,nouser_xattr,commit=0)

Why does it specify "commit=0" at the end? Does it mean that my commit=100 option is not used?

I am using Ubuntu 10.10, 32-bit with the latest updates.

  • 3
    What does grep ' / ' /proc/mounts show? The information in /proc/mounts comes directly from the kernel, whereas mount uses information in /etc/mtab, which might not be up-to-date for /. – Gilles Jul 16 '11 at 19:36
  • 2
    /dev/disk/by-uuid/f51aa298-9ce4-4a19-a323-10df333f34f5 / ext4 rw,noatime,errors=remount-ro,barrier=0,nobh,data=writeback 0 0 – Alex Shtof Jul 16 '11 at 19:38
  • @Gilles - Why would /etc/mtab become out of date? Curious. – boehj Jul 16 '11 at 23:05
  • @boehj /etc/mtab is updated by mount, if it can. / is normally mounted read-only by the kernel or the initrd/initramfs, the remounted read-write as part of the boot process. I'm not sure if the final mount options (from /etc/fstab) are always recorded correctly. – Gilles Jul 16 '11 at 23:11
  • @Gilles - Interesting. – boehj Jul 17 '11 at 0:49

Got it. It seems the problem was with the /usr/lib/pm-utils/power.d/journal-commit file. I edited the above file as root and changed the line


to be


And that's all!

P.S - I have no idea why the script ignores conflicting mount options. I believe it should check for user-specified options and not override them.

  • 2
    That's not a good solution. Next time you update your pm-utils (or whatever owns that file, I'm not an Ubuntu guy) your script may be hosed. The ${JOURNAL_COMMIT_TIME_AC:-100} is a bash thing that says if JOURNAL_COMMIT_TIME_AC is NOT defined, set it to 100. So you need to set that value somewhere that the script reads it. In RedHat systems, it would be somewhere in /etc/sysconfig/ - you need to trace the script and see where it would have read it from. – Aaron D. Marasco Jul 23 '11 at 13:21
  • 1
    Oh, and as for ignoring the /etc/fstab entry, that would be a bug report against the software. Unless there is a distro-specific setup program you were supposed to use that would have set it properly there and recorded it somewhere for the startup script to find. – Aaron D. Marasco Jul 23 '11 at 13:25
  • @Aaron, you are right of course. This is not a solution but a work-around. – Alex Shtof Jul 24 '11 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.