All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chengguang Xu" <cgxu519@gmx.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: jaegeuk@kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: remove default option setting in remount
Date: Thu, 18 Oct 2018 07:28:53 +0200	[thread overview]
Message-ID: <trinity-bae5e1a5-aab2-4c26-9802-3ad64db5b813-1539840533830@msvc-mesg-gmx023> (raw)
In-Reply-To: <d236c53a-b820-da8e-e65b-ff631e7d8bcd@huawei.com>

On 2018/9/25 at 3:41 PM, Chao Yu wrote:

> On 2018/9/22 22:40, cgxu519 wrote:
> > On 09/20/2018 02:29 PM, Chao Yu wrote:
> >> On 2018/9/20 7:54, cgxu519 wrote:
> >>> On 9/19/18 10:02 PM, Chao Yu wrote:
> >>>> On 2018/9/18 21:47, cgxu519 wrote:
> >>>>> On 09/18/2018 09:20 PM, Chao Yu wrote:
> >>>>>> On 2018/9/18 14:23, Chengguang Xu wrote:
> >>>>>>> Currently we set default value to options before parsing remount options,
> >>>>>>> it will cause unexpected change of options which were specified in first
> >>>>>>> mount.
> >>>>>> Can you check below commit? It looks w/o it we may lose default option after
> >>>>>> remount.
> >>>>>>
> >>>>>> 498c5e9fcd10 ("f2fs: add default mount options to remount")
> >>>>> Hi Chao,
> >>>> Hi Chengguang,
> >>>>
> >>>>> It looks like there was a bug in remount at that time, but I think the fix above
> >>>>> is not correct.
> >>>>>
> >>>>> from the patch '498c5e9fcd10', I think it was caused by clearing
> >>>>> sbi->mount_opt.opt before
> >>>>>
> >>>>> parsing. I think remount should not change the options which were specified by
> >>>>> user in
> >>>>>
> >>>>> previous mount unless user specifies in remount.
> >>>> Can you check description in manual of mount.
> >>>>
> >>>> IIRC, old mount option will be record into /etc/mtab or /proc/mounts (for
> >>>> adapting namespace feature), with command of "mount -o remount,rw  /dir", old
> >>>> mount options can be loaded from above config file, and merge them with new
> >>>> specified options.
> >>>>
> >>>> Even we kill old mount options by call default_options() in ->remount, user's
> >>>> old mount option can still be set through parameters.
> >>> Please let me show you different behaviors before/after this patch.
> >>>
> >>>
> >>> [root@x201 cgxu]# uname -a
> >>> Linux x201 4.19.0-rc2+ #51 SMP Wed Sep 19 22:41:20 CST 2018 x86_64
> >>> x86_64 x86_64 GNU/Linux
> >>>
> >>>
> >>> Before:
> >>>
> >>> [root@x201 cgxu]# mount -o fsync_mode=strict /dev/mapper/test-test1
> >>> /mnt/test/test1
> >>> [root@x201 cgxu]# mount | grep test1
> >>> /dev/mapper/test-test1 on /mnt/test/test1 type f2fs
> >>> (rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,fsync_mode=strict)
> >>>
> >>> [root@x201 cgxu]# mount -o remount,background_gc=sync
> >>> /dev/mapper/test-test1 /mnt/test/test1
> >>> [root@x201 cgxu]# mount | grep test1
> >>> /dev/mapper/test-test1 on /mnt/test/test1 type f2fs
> >>> (rw,relatime,background_gc=sync,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix)
> >>>
> >>>
> >>> I only changed background_gc in ->remount, but fsync_mode is implicitly
> >>> set to default value 'posix'.
> >> IMO, the resul is as expected, let's referenced description in manual of mount:
> >>
> >>                The  remount  functionality  follows the standard way how the
> >> mount command works with options from fstab. It means the mount command
> >> doesn't read fstab (or mtab) only when a device and
> >>                dir are fully specified.
> >>
> >>                mount -o remount,rw /dev/foo /dir
> >>
> >>                After this call all old mount options are replaced and
> >> arbitrary stuff from fstab is ignored, except the loop= option which is
> >> internally generated and maintained by the mount command.
> >>
> >>                mount -o remount,rw  /dir
> >>
> >>                After this call mount reads fstab (or mtab) and merges these
> >> options with options from command line ( -o ).
> >>
> >>
> >> So if you want to keep old mount option, you should use:
> >>
> >> mount -o remount,background_gc=sync /mnt/test/test1
> >>
> >> instead of
> >>
> >> mount -o remount,background_gc=sync /dev/mapper/test-test1 /mnt/test/test1
> > 
> > I get your point about how mount command organizes options ,
> > but it seems other filesystem do not initialize mount option in remount.
> > What do you think for that? and if we keep initialization in f2fs,
> > shouldn't we set default value to all mount options for remount?
> 
> I'm okay with this change to keep line with other filesystems.

Hi Chao

Do you agree this patch without change of commit log?

Thanks,
Chengguang

  reply	other threads:[~2018-10-18  5:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18  6:23 [PATCH] f2fs: remove default option setting in remount Chengguang Xu
2018-09-18 13:20 ` Chao Yu
2018-09-18 13:47   ` cgxu519
2018-09-19 14:02     ` Chao Yu
2018-09-19 23:54       ` cgxu519
2018-09-20  6:29         ` Chao Yu
2018-09-22 14:40           ` cgxu519
2018-09-25  7:41             ` Chao Yu
2018-10-18  5:28               ` Chengguang Xu [this message]
2018-10-19  2:15                 ` Chao Yu

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=trinity-bae5e1a5-aab2-4c26-9802-3ad64db5b813-1539840533830@msvc-mesg-gmx023 \
    --to=cgxu519@gmx.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=yuchao0@huawei.com \
    /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.