From: Tetsuhiro Kohada <kohada.t2@gmail.com>
To: Namjae Jeon <namjae.jeon@samsung.com>,
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
Subject: Re: [PATCH] exfat: retain 'VolumeFlags' properly
Date: Wed, 15 Jul 2020 19:06:24 +0900 [thread overview]
Message-ID: <ad0beeab-48ba-ee6d-f4cf-de19ec35a405@gmail.com> (raw)
In-Reply-To: <015801d65a4a$ebedd380$c3c97a80$@samsung.com>
>>>> 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.
OK.
I'll rename both in v2.
>>>> - 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);
Please let me know about this code.
Does this code assume that 'sbi->vol_flags'(last vol_flag value) is not used?
If you use sbi->vol_flags, I think the original idea is fine.
sbi-> vol_flags = new_flag;
p_boot->vol_flags = cpu_to_le16(new_flag);
>> 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.
Hmm?
Does it mean the caller check that volume was dirty at mount, and caller determine
whether to call exfat_set_vol_flags() or not?
If so, MEDIA_FAILUR needs to be set independently of the volume-dirty state.
>> 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.
I think exfat_set_vol_flags() gets a little complicated,
because it needs the followings (with bit operation)
a) Set/Clear VOLUME_DIRTY.
b) Set MEDIA_FAILUR.
c) Do not change other flags.
d) Retain VOLUME_DIRTY/MEDIA_FAILUR as it is when mounted.
'vol_flags_noclear' is used for d).
Bit-by-bit operation makes the code redundant.
I think it's not a bad way to handle multiple bits.
What do you think?
BR
---
Tetsuhiro Kohada <kohada.t2@gmail.com>
next prev parent reply other threads:[~2020-07-15 10:06 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
2020-07-15 10:06 ` Tetsuhiro Kohada [this message]
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=ad0beeab-48ba-ee6d-f4cf-de19ec35a405@gmail.com \
--to=kohada.t2@gmail.com \
--cc=Kohada.Tetsuhiro@dc.MitsubishiElectric.co.jp \
--cc=Mori.Takahiro@ab.MitsubishiElectric.co.jp \
--cc=Motai.Hirotaka@aj.MitsubishiElectric.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).