All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Namjae Jeon" <namjae.jeon@samsung.com>
To: <Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp>
Cc: <Mori.Takahiro@ab.MitsubishiElectric.co.jp>,
	<Motai.Hirotaka@aj.MitsubishiElectric.co.jp>,
	"'Sungjong Seo'" <sj1557.seo@samsung.com>,
	<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	"'Tetsuhiro Kohada''" <kohada.t2@gmail.com>
Subject: RE: [PATCH] exfat: retain 'VolumeFlags' properly
Date: Wed, 15 Jul 2020 10:54:48 +0900	[thread overview]
Message-ID: <015801d65a4a$ebedd380$c3c97a80$@samsung.com> (raw)
In-Reply-To: <TY2PR01MB2875C88DD10CC13D0C70DE1690610@TY2PR01MB2875.jpnprd01.prod.outlook.com>

> Thanks for your reply.
> 
> > > Also, rename ERR_MEDIUM to MED_FAILURE.
> > I think that MEDIA_FAILURE looks better.
> 
> I think so too.
> If so, should I change VOL_DIRTY to VOLUME_DIRTY?
Yes, maybe.
> 
> > > -int exfat_set_vol_flags(struct super_block *sb, unsigned short
> > > new_flag)
> > > +int exfat_set_vol_flags(struct super_block *sb, unsigned short
> > > +new_flags)
> > >  {
> > >  	struct exfat_sb_info *sbi = EXFAT_SB(sb);
> > >  	struct boot_sector *p_boot = (struct boot_sector *)sbi->boot_bh->b_data;
> > >  	bool sync;
> > If dirty bit is set in on-disk volume flags, we can just return 0 at the beginning of this function ?
> 
> That's right.
> Neither 'set VOL_DIRTY' nor 'set VOL_CLEAN' makes a change to volume flags.
> 
> 
> > > +	if (new_flags == VOL_CLEAN)
> > > +		new_flags = (sbi->vol_flags & ~VOL_DIRTY) | sbi->vol_flags_noclear;
> > > +	else
> > > +		new_flags |= sbi->vol_flags;
> > > +
> > >  	/* flags are not changed */
> > > -	if (sbi->vol_flag == new_flag)
> > > +	if (sbi->vol_flags == new_flags)
> > >  		return 0;
> > >
> > > -	sbi->vol_flag = new_flag;
> > > +	sbi->vol_flags = new_flags;
> > >
> > >  	/* skip updating volume dirty flag,
> > >  	 * if this volume has been mounted with read-only @@ -114,9 +119,9
> > > @@ int exfat_set_vol_flags(struct super_block *sb, unsigned short new_flag)
> > >  	if (sb_rdonly(sb))
> > >  		return 0;
> > >
> > > -	p_boot->vol_flags = cpu_to_le16(new_flag);
> > > +	p_boot->vol_flags = cpu_to_le16(new_flags);
> > How about set or clear only dirty bit to on-disk volume flags instead
> > of using
> > sbi->vol_flags_noclear ?
> >        if (set)
> >                p_boot->vol_flags |= cpu_to_le16(VOL_DIRTY);
> >        else
> >                p_boot->vol_flags &= cpu_to_le16(~VOL_DIRTY);
> 
> In this way, the initial  VOL_DIRTY cannot be retained.
> The purpose of this patch is to avoid losing the initial VOL_DIRTY and MED_FAILURE.
> Furthermore, I'm also thinking of setting MED_FAILURE.
I know what you do. I mean this function does not need to be called if volume dirty
Is already set on on-disk volume flags as I said earlier.
> 
> However, the formula for 'new_flags' may be a bit complicated.
> Is it better to change to the following?
> 
> 	if (new_flags == VOL_CLEAN)
> 		new_flags = sbi->vol_flags & ~VOL_DIRTY
> 	else
> 		new_flags |= sbi->vol_flags;
> 
> 	new_flags |= sbi->vol_flags_noclear;
> 
> 
> one more point,
> Is there a better name than 'vol_flags_noclear'?
> (I can't come up with a good name anymore)
It looks complicated. It would be better to simply set/clear VOLUME DIRTY bit.

Thanks!
> 
> BR
> ---
> Kohada Tetsuhiro <Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp>


  reply	other threads:[~2020-07-15  1:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200708095813epcas1p2277cdf7de6a8bb20c27bcd030eec431f@epcas1p2.samsung.com>
2020-07-08  9:57 ` [PATCH] exfat: retain 'VolumeFlags' properly Tetsuhiro Kohada
2020-07-13  4:52   ` Namjae Jeon
2020-07-14  1:56     ` Kohada.Tetsuhiro
2020-07-15  1:54       ` Namjae Jeon [this message]
2020-07-15 10:06         ` Tetsuhiro Kohada
2020-07-30  6:24           ` Tetsuhiro Kohada
2020-07-30  6:59             ` Namjae Jeon
2020-07-31  1:29               ` Tetsuhiro Kohada

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='015801d65a4a$ebedd380$c3c97a80$@samsung.com' \
    --to=namjae.jeon@samsung.com \
    --cc=Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp \
    --cc=Mori.Takahiro@ab.MitsubishiElectric.co.jp \
    --cc=Motai.Hirotaka@aj.MitsubishiElectric.co.jp \
    --cc=kohada.t2@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.