[SOLVED] Why root is remounted with commit=0 (=600 specified in fstab) at the end of start-up?

*Dark Dragon* · 01-10-2012, 05:04 PM

My problem is that in fstab I have specified commit=600 but during start-up
something remounts root with commit=0 option. Here is the log:

Code:

% dmesg | grep sdd1 | grep re-
[   14.918717] EXT4-fs (sdd1): re-mounted. Opts: (null)
[   15.036666] EXT4-fs (sdd1): re-mounted. Opts: user_xattr,errors=remount-
ro,commit=600
[   38.425387] EXT4-fs (sdd1): re-mounted. Opts: user_xattr,errors=remount-
ro,commit=600,commit=0

Last line is the last in dmesg, so this happens at the end of the start-up.

If somebody have an idea why this is happening and how can I stop this, please help me. If not, at least some clues how to find what script/program is doing this would be appreciated.

I'm using fresh (less than 2 weeks old) installation of Debian GNU/Linux Testing and KDE. I know I can remount it manually or write startup script that remounts it one more time, but I want to find the source of the problem and fix it.

*Dark Dragon* · 01-10-2012, 09:28 PM

Found it: /usr/lib/pm-utils/power.d/journal-commit

This script is responsible for the problem. To solve, I removed "commit=600" from fstab and changed variable for "commit" option when on AC power in the script.

I do not need it on my workstation (working 24/7) but KDE requires pm-utils so I cannot purge it. I'm really surprised by the fact that everywhere everybody says to put "commit" option in fstab where it does have ZERO effect if you have KDE (and therefore pm-utils) installed. And I did not find anything in any manual about necessity to edit "journal-commit" script if I'm not happy with default "commit=0".

Hopefully information in this topic will be useful to somebody.

*Dark Dragon* · 01-11-2012, 10:06 AM

Editing /usr/lib/pm-utils/power.d/journal-commit is not necessary (and bad idea because upgrade can overwrite it with new version). Using "commit" option in /etc/fstab is bad idea too. So how to do it properly? After some research I think that putting these lines in /etc/sysctl.d/local.conf is the solution:

Code:

vm.dirty_writeback_centisecs = 60000
vm.dirty_expire_centisecs = 120000

I set dirty_expire_centisecs twice the value of dirty_writeback_centisecs. Please note that with these settings it is possible to lose up to 20 minutes of work. So if you are not on UPS-protected Xeon workstation with RDIMM memory like I am, you probably want to use smaller values, for typical UPS-protected desktop PC or laptop 6000 and 12000 (1 and 2 minutes respectively) are good values (IMO).