nolazytime remount

nolazytime remount

[Karel Zak]

We had issue with "lazytime" remount two mouths ago. This is already
fixed by Ted's patch a2fd66d06. So, now you can enable lazytime by
remount with MS_LAZYTIME flag, but how I can disable lazytime?

enable lazytime (works as expected):

 # findmnt /mnt/test
 TARGET    SOURCE    FSTYPE OPTIONS
 /mnt/test /dev/sdc1 ext4   rw,relatime,stripe=32,data=ordered

 # mount -o remount,lazytime /mnt/test

 # findmnt /mnt/test
 TARGET    SOURCE    FSTYPE OPTIONS
 /mnt/test /dev/sdc1 ext4   rw,relatime,lazytime,stripe=32,data=ordered


disable lazytime by "nolazytime":

 # mount -o remount,nolazytime /mnt/test
 # findmnt /mnt/test
 TARGET    SOURCE    FSTYPE OPTIONS
 /mnt/test /dev/sdc1 ext4   rw,relatime,lazytime,stripe=32,data=ordered
                                        ^^^^^^^^

In this case mount(8) command generates:
  mount("/dev/sdc1", "/mnt/test", 0x562ed2f7e210, MS_REMOUNT|MS_RELATIME, "stripe=32,data=ordered") = 0
syscall.


It seems that ext4_remount() allows to enable the option by MS_LAZYTIME,
but there is no sb->s_flags &= ~MS_LAZYTIME at all. It seems like a
regression, because old string based solution (handle_mount_opt()) contains:

  case Opt_nolazytime:
       sb->s_flags &= ~MS_LAZYTIME;
       return 1;


>From my point of view, a2fd66d06 commit is insufficient, for ext4_remount()
we also need "else" for MS_LAZYTIME:

	if (*flags & MS_LAZYTIME)
		sb->s_flags |= MS_LAZYTIME;
    else
        sb->s_flags &= ~MS_LAZYTIME;


The another possibility is that "lazytime" is possible enable only --
if yes, then handle_mount_opt() should be fixed to not provide
Opt_nolazytime.

Ted?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: nolazytime remount

[tytso]

On Wed, Aug 19, 2015 at 10:21:44AM +0200, Karel Zak wrote:
> 
> It seems that ext4_remount() allows to enable the option by MS_LAZYTIME,
> but there is no sb->s_flags &= ~MS_LAZYTIME at all. It seems like a
> regression, because old string based solution (handle_mount_opt()) contains:
> 
>   case Opt_nolazytime:
>        sb->s_flags &= ~MS_LAZYTIME;
>        return 1;
> 
> 
> From my point of view, a2fd66d06 commit is insufficient, for ext4_remount()
> we also need "else" for MS_LAZYTIME:
> 
> 	if (*flags & MS_LAZYTIME)
> 		sb->s_flags |= MS_LAZYTIME;
>     else
>         sb->s_flags &= ~MS_LAZYTIME;
> 
> 
> The another possibility is that "lazytime" is possible enable only --
> if yes, then handle_mount_opt() should be fixed to not provide
> Opt_nolazytime.

Yeah, I noticed this when I coded up a2fd66d06, but the problem is
that if you are using an older version of mount, then a command which
does *not* mention lazytime will silently ending up disabling
lazttime.  (This a generic problem any time we migrate whether mount
program or the kernel is supposed to parse a particular mount option
where we toggle state by the presence or absence of a MS_XXX bit; so
we could also solve this problem by burning another mount option bit
for MS_NOLAZYTIME, but we don't have any bits left.)

So the question is which is worse.  Causing people who are using newer
kernels, but older versions of mount, and who want to use lazytime, to
have to specify it on every single "mount -o remount" command (and
this includes someone who sets lazytime using rootflags, and now needs
to start hacking systemd binaries since there is no longer a shell
program to remount file systems read-write --- why I hate systemd, but
that's a rant for another forum), or make it impossible for people who
are using newer versions of mount who want to disable lazytime.

I *think* the number of people who would want to disable lazytime is
smaller, which why I made the decision that I did, so my thinking was
to leave it this way until the next version of Debian stable ships,
and then change the kernel to allow the newer versions of mount to
disable lazytime at that point.

I suppose I could set up make this be switchable, so people could
specify ext4.support_older_mount=1 on the boot command-line option,
but this seems really ugly, and then people would need to remember to
remove said ugly command-line option from their grub config file when
they update to a newer mount command.

Blargh; no really good solutions here.  Does anyone have any thoughts
or suggestions about how to handle this better?

   	       	     	    	   	- Ted

Re: nolazytime remount

[Karel Zak]

On Wed, Aug 19, 2015 at 02:15:16PM +0000, tytso@mit.edu wrote:
> I *think* the number of people who would want to disable lazytime is
> smaller, which why I made the decision that I did, so my thinking was
> to leave it this way until the next version of Debian stable ships,
> and then change the kernel to allow the newer versions of mount to
> disable lazytime at that point.

Yes, I think the long term solution is to support MS_LAZYTIME flags
only and remove "[no]lazytime" strings from ext4 mount options parser.

> I suppose I could set up make this be switchable, so people could
> specify ext4.support_older_mount=1 on the boot command-line option,
> but this seems really ugly, and then people would need to remember to
> remove said ugly command-line option from their grub config file when
> they update to a newer mount command.

It seems like over-engineering to introduce another comman-line option
to fix the current mount option. It would be better to keep it simple
and stupid :-)

If you want to make it configurable than use #ifdef and kconfig --
then distros like Debian may enable the obsolete string-based
"lazytime".

I don't think we have to support all permutation without kernel
recompilation, the important is to support generic use-cases and allow
to distros to compose and distribute consistent stuff. The current
situation when you have new kernel, new mount(8), but you cannot
"-o remount,nolazytime" is bad.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com