All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Namjae Jeon <linkinjeon@gmail.com>
Cc: jaegeuk.kim@samsung.com, linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Namjae Jeon <namjae.jeon@samsung.com>,
	Pankaj Kumar <pankaj.km@samsung.com>
Subject: Re: [PATCH 1/2] f2fs: add remount_fs callback support
Date: Thu, 06 Jun 2013 15:52:16 +0800	[thread overview]
Message-ID: <51B03FB0.80306@cn.fujitsu.com> (raw)
In-Reply-To: <CAKYAXd_jFuG00-HWQREKieXdqBGEAs+W0imvYZjCpGAH5S4H9A@mail.gmail.com>

Hi Namjae,

On 06/05/2013 12:34 PM, Namjae Jeon wrote:

> 2013/6/4 Gu Zheng <guz.fnst@cn.fujitsu.com>:
>> On 06/01/2013 03:20 PM, Namjae Jeon wrote:
>>
>>> From: Namjae Jeon <namjae.jeon@samsung.com>
>>>
>>> Add the f2fs_remount function call which will be used
>>> during the filesystem remounting. This function
>>> will help us to change the mount options specific to
>>> f2fs.
>>>
>>> Also modify the f2fs background_gc mount option, which
>>> will allow the user to dynamically trun on/off the
>>> garbage collection in f2fs based on the background_gc
>>> value. If background_gc=0, Garbage collection will
>>> be turned off & if background_gc=1, Garbage collection
>>> will be truned on.
>>
>>
>> Hi Namjae,
> Hi. Gu.
> 
>>   I think splitting these two changes into single ones seems better.
>> Refer to the inline comments.
> I don't think so. Mount option background_gc is changed to make
> remount_fs working in the correct way.

Yes, I know. Maybe you somewhat misread my words. 
Though remount_fs is dependent on changing background_gc option, but the change of background_gc option
and the adding remount_fs support are two different changes.
In order to make each patch simple and clear, maybe you need to split into single ones,
such as:
[PATCH 1/3] f2fs: Modify the f2fs background_gc mount option
[PATCH 2/3] f2fs: add remount_fs callback support
[PATCH 3/3] f2fs: reorganise the function get_victim_by_default

Just a personal suggestion, if you think it is worthless, please ignore it.:)


> 
>>
>> Thanks,
>> Gu
>>
>>
>> Though simply option show is enough, but I think the "background_gc=on/off" is more friendly.
> Yes, Agree. I will update.
> 
>>
>>> +
>>> +     /**
>>> +      * We stop the GC thread if FS is mounted as RO
>>> +      * or if background_gc = 0 is passed in mount
>>> +      * option. Also sync the filesystem.
>>> +      */
>>> +     if ((*flags & MS_RDONLY) || !test_opt(sbi, BG_GC)) {
>>
>>
>> Another condition: The old mount is not RO.
> I don't think that it is needed. I think current condition check can
> be covered about all cases.
> Am I missing something ?

Maybe. If the old mount is RO, so does the remount. It still can pass the judgement here, right?
Though the following stop_gc_thread() and f2fs_sync_fs() can handle this case well, but this
is unnecessary and needless. If we add additional judgement of whether old mount is not RO can avoid this.

Thanks,
Gu

> 
>>
>>> +             stop_gc_thread(sbi);
>>> +             f2fs_sync_fs(sb, 1);
>>> +     } else if (test_opt(sbi, BG_GC) && !sbi->gc_thread) {
>>> +             err = start_gc_thread(sbi);
>>> +             if (err)
>>> +                     goto restore_opts;
>>> +     }
>>> +
>>> +     /* Update the POSIXACL Flag */
>>> +      sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
>>> +             (test_opt(sbi, POSIX_ACL) ? MS_POSIXACL : 0);
>>
>>
>> Maybe you forget to update the flags with MS_RDONLY or ~MS_RDONLY, if the flags changed.
> No, we don't need to check this flags. sb-s_flags will be updated by
> MS_REMOUNT of vfs.(do_remount_sb)
> 
>>
>>> +     return 0;
>>> +
>>> +restore_opts:
>>> +     sb->s_flags = old_sb_flags;
>>
>>
>> There is no need to restore sb->s_flags, parse_options() did not change it.
>> no need to store the old sb->s_flags too.
> Yes, right, I will update.
> 
>>
>>>
>>> -     /* After POR, we can run background GC thread */
>>> -     err = start_gc_thread(sbi);
>>> -     if (err)
>>> -             goto fail;
>>> +     /* After POR, we can run background GC thread.*/
>>> +     if (!(sb->s_flags & MS_RDONLY)) {
>>> +             /**
>>> +              * If filesystem is mounted as read-only then
>>> +              * do not start the gc_thread.
>>> +              */
>>
>> It seems that the comment here is against with the logic.
> hum.. Okay, I will update comment to avoid some confusion.
> 
> Thanks for review :)
> I will post v2 patch including your opinion soon.
> 

  reply	other threads:[~2013-06-06  7:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01  7:20 [f2fs-dev] [PATCH 1/2] f2fs: add remount_fs callback support Namjae Jeon
2013-06-01  7:20 ` Namjae Jeon
2013-06-04  4:14 ` [f2fs-dev] " Gu Zheng
2013-06-04  4:14   ` Gu Zheng
2013-06-05  4:34   ` [f2fs-dev] " Namjae Jeon
2013-06-05  4:34     ` Namjae Jeon
2013-06-06  7:52     ` Gu Zheng [this message]
2013-06-06 13:05       ` [f2fs-dev] " Namjae Jeon
2013-06-06 13:05         ` Namjae Jeon
  -- strict thread matches above, loose matches on Subject: below --
2013-06-16  0:48 Namjae Jeon
2013-06-17  2:39 ` Gu Zheng

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=51B03FB0.80306@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=jaegeuk.kim@samsung.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    --cc=pankaj.km@samsung.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.