Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.
Adam Borowski <firstname.lastname@example.org> writes:
> On Sat, May 07, 2011 at 10:43:29PM -0400, Ted Ts'o wrote:
>> This isn't a bug in e2fsprogs; e2fsprogs has absolutely nothing to do
>> with mounting the file system.
>> Debian simply doesn't support the mount options for the root file
>> system in /etc/fstab having any effect on how the root file system is
>> mounted. The root file system is mounted by the kernel, and the mount
>> options used by the kernel are specified by the rootflags= option on
>> the kernel's boot command line.
>> Should we try to make this work (at best badly) since a change in
>> mount options in /etc/fstab would only take effect at the next
>> mkinitramfs and/or update-grub invocation? Or should we just close
>> out this bug and say, "tough luck, kid; if you want to change the root
>> file system's mount options, you need to edit your kernel's boot
>> options using whatever bootloader you might happen to be using"?
Or the init scripts could "mount -oremount,commit=300 /". Most options
can be altered throught remount. For the few remaining ones
(e.g. data=writeback) editing the kernel's boot options is probably ok.
The init scripts already do this for read-only / read-write. Why doesn't
this work for commit= too?
> It is really annoying to have to edit the same thing twice and face boot
> failures if you forgot that. There are legitimate reasons you might want to
> change boot options often.
> Would it be possible to ask the kernel what root fs options it received?
> The line in fstab could then be changed to include only options that change,
> without having to redundantly specify device, fs type, subvolume and the
/proc/mounts shows the current options.
> Rationale: as you said, there are so many ways to configure kernel's command
> line, the source for kernel's configuration might even be not present on the
> system at all. Trying to update that configuration from /etc/fstab seems to
> be impossible, but going the other way around seems relatively easy.
> With /etc/fstab no longer having authoritative data for the root fs, one
> would have to change fsck and mount, but since there are few consumers of
> /etc/fstab, that's not a show stopper.