Ext4 overrides the commit=100 mount option with commit=0

ext4mount

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.

Best Answer

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

JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-0}

to be

JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-100}

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.

Related Solutions

Unable to mount raid on the NAS, trying to rescue the data, how should I proceed

This is an attempt to summarize from the chat troubleshooting session.

The setup turns out to be physical disk -> mdraid raid1 -> LVM. So there are several layers to work through. The old setup was (due to unfortunate prior recovery efforts) not available.

However, the NAS gui had been used to create another volume on a different disk, and thankfully the GUI created the new volume exactly the same way. So it was possible to discover the setup from the new disk:

mdadm -E new-disk provided the offset to the start of the data, under the mdraid layer (2048 sectors).
dmsetup table provided the start block of the logical volume (relative to the start of the physical volume) (1152 sectors)
There is a magic number (0x53ef) in the third sector of an ext4 volume. Using dd and xxd, we verified that the magic number is present at that offset on the disk we're trying to recover data from.

Armed with the start sector of the ext4 filesystem, you can use a read-only loop device to recover the data:

# losetup /dev/loop0 -o $((512*(1152+2048))) -r /dev/sda1
# mount -text4 -o ro /dev/loop0 /mnt

And then copy it off.

How to mount a filesystem from a given USB bus:device

When you see the handlers like gphoto2:// and smb:// these are special interfaces that the GNOME desktop or whatever file browser you're using is making available to access these devices. In the case of gphoto2, the desktop is using the application gphoto2`

lsof

The only way I can think to gain access to a mount such as this would be to mount it as you did before using Nautilus or whatever file browser, and then using a tool such as lsof to see what files/devices are opened by Nautilus.

$ lsof -p $(pgrep nautilus)

But if you're having to connect to your phone via gphoto2 then you're likely not mounting the device a a mass storage device but rather a PTP - Picture Transfer Protocol. There's a Linux FUSE implementation for PTP too.

gvfs?

I would also look in your $HOME directory for a sub-directory called .gvfs. Usually when GNOME or Nautilus are doing the mounting this directory is created as a convenience.

In newer versions of GNOME (3+) this directory has moved and is now here, /run/user/$UID/gvfs.

Example

$ ls -l /run/user/$UID/gvfs/smb-share\:server\=tank\,share\=t 
total 2
drwx------. 1 saml saml    0 Oct 31 09:16 Development
drwx------. 1 saml saml    0 Nov 18 14:52 home
drwx------. 1 saml saml    0 May 14  2013 incoming
...

NOTE: That's a environment variable $UID that is often set in Bash on most modern systems. If it isn't set you can find your user's ID like so:

$ id
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023