All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
To: Eric Sandeen <sandeen@redhat.com>, Karel Zak <kzak@redhat.com>
Cc: linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: Lazytime undone by/not working with remount?
Date: Mon, 18 May 2015 17:36:52 +0200	[thread overview]
Message-ID: <555A0714.8010806@googlemail.com> (raw)
In-Reply-To: <555A02CF.1000506@redhat.com>


On 05/18/15 17:18, Eric Sandeen wrote:
> On 5/18/15 3:21 AM, Karel Zak wrote:
>> On Sat, May 16, 2015 at 04:26:33PM +0200, Holger Hoffstätte wrote:
>>>> playing with lazytime on 4.0.4-rc1 + yesterday's fencepost patch) I noticed
>>>> something odd. Mounting secondary (non-root) partitions with lazytime works
>>>> fine, but / does not seem to retain the value from fstab - apparently because
>>>> it is remounted rw during boot, and lazytime gets swallowed/undone.
>>>>
>>>> Same effect when trying to remount manually with lazytime:
>>>>
>>>> tux>findmnt /
>>>> TARGET SOURCE    FSTYPE OPTIONS
>>>> /      /dev/sda1 ext4   rw,noatime
>>>>
>>>> tux>mount -o lazytime,remount / 
>>>>
>>>> tux>dmesg 
>>>> [ 5208.482505] EXT4-fs (sda1): re-mounted. Opts: (null)
>>>>
>>>> tux>findmnt /                  
>>>> TARGET SOURCE    FSTYPE OPTIONS
>>>> /      /dev/sda1 ext4   rw,noatime
>>>>
>>>> tux>mount --version
>>>> mount from util-linux 2.26.2 (libmount 2.26.0: assert, debug)
> 
> And what does /proc/mounts say?  That'll tell you what is actually set
> on the superblock.  Works here, on 4.1.0-rc2:
> 
> # mount /dev/sdb1 /mnt/test
> # mount -o remount,lazytime /mnt/test
> # grep sdb1 /proc/mounts 
> /dev/sdb1 /mnt/test ext4 rw,lazytime,seclabel,relatime,data=ordered 0 0
> 
> # dmesg | tail -n 2
> [516203.450943] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
> [516211.222020] EXT4-fs (sdb1): re-mounted. Opts: lazytime

When I used util-linux 2.26.2 /proc/mounts never contained lazytime for the root device (sda1), despite the fact that it and other partitions explicitly had lazytime in fstab. Secondary drives & partitions *did* get the value right from the start, i.e. anything that didn't go through a ro->remount transition.

It all works reliably with 2.25.x since - as Karel mentioned - the bug seems with ext4's remount logic in combination with readonly (as was the case with the root partition) and mount now actually sending the MS_LAZYTIME flag, instead of relying on ext4's builtin extra handling.

-h

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-05-18 15:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-16 11:05 Lazytime undone by/not working with remount? Holger Hoffstätte
2015-05-16 14:26 ` Holger Hoffstätte
     [not found] ` <55575399.6010801@googlemail.com>
2015-05-18  8:21   ` Karel Zak
2015-05-18 15:18     ` Eric Sandeen
2015-05-18 15:36       ` Holger Hoffstätte [this message]
2015-05-18 15:23     ` Theodore Ts'o
2015-05-18 15:38       ` Holger Hoffstätte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=555A0714.8010806@googlemail.com \
    --to=holger.hoffstaette@googlemail.com \
    --cc=kzak@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.