All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuhiro Kohada <kohada.t2@gmail.com>
To: Sungjong Seo <sj1557.seo@samsung.com>
Cc: kohada.tetsuhiro@dc.mitsubishielectric.co.jp,
	mori.takahiro@ab.mitsubishielectric.co.jp,
	motai.hirotaka@aj.mitsubishielectric.co.jp,
	'Namjae Jeon' <namjae.jeon@samsung.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] exfat: remove EXFAT_SB_DIRTY flag
Date: Fri, 12 Jun 2020 19:22:34 +0900	[thread overview]
Message-ID: <b29d254b-212a-bfcb-ab7c-456f481b85c8@gmail.com> (raw)
In-Reply-To: <219a01d64094$5418d7a0$fc4a86e0$@samsung.com>

On 2020/06/12 17:34, Sungjong Seo wrote:
>> remove EXFAT_SB_DIRTY flag and related codes.
>>
>> This flag is set/reset in exfat_put_super()/exfat_sync_fs() to avoid
>> sync_blockdev().
>> However ...
>> - exfat_put_super():
>> Before calling this, the VFS has already called sync_filesystem(), so sync
>> is never performed here.
>> - exfat_sync_fs():
>> After calling this, the VFS calls sync_blockdev(), so, it is meaningless
>> to check EXFAT_SB_DIRTY or to bypass sync_blockdev() here.
>> Not only that, but in some cases can't clear VOL_DIRTY.
>> ex:
>> VOL_DIRTY is set when rmdir starts, but when non-empty-dir is detected,
>> return error without setting EXFAT_SB_DIRTY.
>> If performe 'sync' in this state, VOL_DIRTY will not be cleared.
>>
>> Remove the EXFAT_SB_DIRTY check to ensure synchronization.
>> And, remove the code related to the flag.
>>
>> Signed-off-by: Tetsuhiro Kohada <kohada.t2@gmail.com>
>> ---
>>   fs/exfat/balloc.c   |  4 ++--
>>   fs/exfat/dir.c      | 16 ++++++++--------
>>   fs/exfat/exfat_fs.h |  5 +----
>>   fs/exfat/fatent.c   |  7 ++-----
>>   fs/exfat/misc.c     |  3 +--
>>   fs/exfat/namei.c    | 12 ++++++------
>>   fs/exfat/super.c    | 11 +++--------
>>   7 files changed, 23 insertions(+), 35 deletions(-)
>>
> [snip]
>>
>> @@ -62,11 +59,9 @@ static int exfat_sync_fs(struct super_block *sb, int
>> wait)
>>
>>   	/* If there are some dirty buffers in the bdev inode */
>>   	mutex_lock(&sbi->s_lock);
>> -	if (test_and_clear_bit(EXFAT_SB_DIRTY, &sbi->s_state)) {
>> -		sync_blockdev(sb->s_bdev);
>> -		if (exfat_set_vol_flags(sb, VOL_CLEAN))
>> -			err = -EIO;
>> -	}
> 
> I looked through most codes related to EXFAT_SB_DIRTY and VOL_DIRTY.
> And your approach looks good because all of them seem to be protected by
> s_lock.
> 
> BTW, as you know, sync_filesystem() calls sync_fs() with 'nowait' first,
> and then calls it again with 'wait' twice. No need to sync with lock twice.
> If so, isn't it okay to do nothing when wait is 0?

I also think  ‘do nothing when wait is 0’ as you say, but I'm still not sure.

Some other Filesystems do nothing with nowait and just return.
However, a few Filesystems always perform sync.

sync_blockdev() waits for completion, so it may be inappropriate to call with  nowait. (But it was called in the original code)

I'm still not sure, so I excluded it in this patch.
Is it okay to include it?


>> +	sync_blockdev(sb->s_bdev);
>> +	if (exfat_set_vol_flags(sb, VOL_CLEAN))
>> +		err = -EIO;
>>   	mutex_unlock(&sbi->s_lock);
>>   	return err;
>>   }
>> --
>> 2.25.1
> 
> 

BR
---
Tetsuhiro Kohada <kohada.t2@gmail.com>


  reply	other threads:[~2020-06-12 10:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200612012902epcas1p4194d6fa3b3f7c46a8becb9bb6ce23d56@epcas1p4.samsung.com>
2020-06-12  1:28 ` [PATCH] exfat: remove EXFAT_SB_DIRTY flag Tetsuhiro Kohada
2020-06-12  8:34   ` Sungjong Seo
2020-06-12 10:22     ` Tetsuhiro Kohada [this message]
2020-06-15  2:59       ` Sungjong Seo
2020-06-15  8:31         ` Kohada.Tetsuhiro
2020-06-12  8:48 Markus Elfring
2020-06-12 10:01 ` Greg KH

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=b29d254b-212a-bfcb-ab7c-456f481b85c8@gmail.com \
    --to=kohada.t2@gmail.com \
    --cc=kohada.tetsuhiro@dc.mitsubishielectric.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mori.takahiro@ab.mitsubishielectric.co.jp \
    --cc=motai.hirotaka@aj.mitsubishielectric.co.jp \
    --cc=namjae.jeon@samsung.com \
    --cc=sj1557.seo@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.