Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I'm running a fairly fresh and vanilla 10.10 install, built from scratch about a month ago on an Acer Aspire 5742 laptop. I use openbox as my window manager and run neither the KDE nor Gnome desktop stacks. I haven't yet figured out how to get the system to hibernate when low on battery power, so I get occasional power outages.

I've noticed that when my laptop switches over to battery power, my ext* partitions are remounted with the option commit=600.

When I switch back to AC, there is another set of remounts with commit=0.

This is apparent from entries in /var/log/syslog like

Mar 31 14:48:48 gatsby kernel: [414710.189306] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600
Mar 31 14:48:48 gatsby kernel: [414710.324137] EXT4-fs (dm-1): re-mounted. Opts: commit=600
Mar 31 14:48:48 gatsby kernel: [414710.749636] EXT4-fs (dm-2): re-mounted. Opts: commit=600
Mar 31 16:35:58 gatsby kernel: [421128.882072] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=0
Mar 31 16:35:58 gatsby kernel: [421129.083283] EXT4-fs (dm-1): re-mounted. Opts: commit=0
Mar 31 16:35:59 gatsby kernel: [421129.724136] EXT4-fs (dm-2): re-mounted. Opts: commit=0

The mount manual explains the meaning of the count option with respect to the ext3 filesystem thusly:

commit=nrsec
       Sync all data and metadata every nrsec seconds.
       The default value is 5 seconds. Zero means default.

What does this mean, exactly? It seems to imply that writes may be cached for up to 10 minutes. Does this mean that there could be filesystem corruption, or that some changes may go unsaved if my battery power runs out?

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

It shouldn't result in file system corruption (it is a journaling file system, after all), but it may result in lost work.

The reason for the behaviour is that spinning up the disk uses power, and by waiting longer before performing a journal commit it may be possible to perform multiple writes in one go, resulting in fewer spin ups and better battery life.

If this is causing problems for you, you can alter the commit interval when on battery. The changes are performed by the pm-utils package, so create a file under /etc/pm/config.d/ (the name doesn't matter) with the following contents:

JOURNAL_COMMIT_TIME_BAT=300

The above sets the timeout to 5 minutes. You can tweak it as needed.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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