Date:   Sun, 9 Aug 2020 02:47:48 +0900
From:   "Sungjong Seo" <sj1557.seo@...sung.com>
To:     "'Tetsuhiro Kohada'" <kohada.t2@...il.com>
Cc:     <kohada.tetsuhiro@...mitsubishielectric.co.jp>,
        <mori.takahiro@...mitsubishielectric.co.jp>,
        <motai.hirotaka@...mitsubishielectric.co.jp>,
        "'Namjae Jeon'" <namjae.jeon@...sung.com>,
        <linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] exfat: remove EXFAT_SB_DIRTY flag

> On 2020/06/18 22:11, Sungjong Seo wrote:
> >> BTW
> >> Even with this patch applied,  VOL_DIRTY remains until synced in the
> >> above case.
> >> It's not  easy to reproduce as rmdir, but I'll try to fix it in the
> future.
> >
> > I think it's not a problem not to clear VOL_DIRTY under real errors,
> > because VOL_DIRTY is just like a hint to note that write was not
> finished clearly.
> >
> > If you mean there are more situation like ENOTEMPTY you mentioned,
> > please make new patch to fix them.
> 
> 
> When should VOL_DIRTY be cleared?
> 
> The current behavior is ...
> 
> Case of  mkdir, rmdir, rename:
>    - set VOL_DIRTY before operation
>    - set VOL_CLEAN after operating.
> In async mode, it is actually written to the media after 30 seconds.
> 
> Case of  cp, touch:
>    - set VOL_DIRTY before operation
>    - however, VOL_CLEAN is not called in this context.
> VOL_CLEAN will call by sync_fs or unmount.
> 
> I added VOL_CLEAN in last of __exfat_write_inode() and exfat_map_cluster().
> As a result, VOL_DIRTY is cleared with cp and touch.
> However, when copying a many files ...
>   - Async mode: VOL_DIRTY is written to the media twice every 30 seconds.
>   - Sync mode: Of course,  VOL_DIRTY and VOL_CLEAN to the media for each
> file.
> 
> Frequent writing VOL_DIRTY and VOL_CLEAN  increases the risk of boot-
> sector curruption.
> If the boot-sector corrupted, it causes the following serious problems  on
> some OSs.
>   - misjudge as unformatted
>   - can't judge as exfat
>   - can't repair
> 
> I want to minimize boot sector writes, to reduce these risk.
> 
> I looked vfat/udf implementation, which manages similar dirty information
> on linux, and found that they ware mark-dirty at mount and cleared at
> unmount.
> 
> Here are some ways to clear VOL_DIRTY.
> 
> (A) VOL_CLEAN after every write operation.
>    :-) Ejectable at any time after a write operation.
>    :-( Many times write to Boot-sector.
> 
> (B) dirty at mount, clear at unmount (same as vfat/udf)
>    :-) Write to boot-sector twice.
>    :-( It remains dirty unless unmounted.
>    :-( Write to boot-sector even if there is no write operation.
> 
> (C) dirty on first write operation, clear on unmount
>    :-) Writing to boot-sector is minimal.
>    :-) Will not write to the boot-sector if there is no write operation.
>    :-( It remains dirty unless unmounted.
> 
> (D) dirty on first write operation,  clear on sync-fs/unmount
>   :-) Writing to boot-sector can be reduced.
>   :-) Will not write to the boot-sector if there is no write operation.
>   :-) sync-fs makes it clean and ejectable immidiately.
>   :-( It remains dirty unless sync-fs or unmount.
>   :-( Frequent sync-fs will  increases writes to boot-sector.
> 
> I think it should be (C) or(D).
> What do you think?
> 

First of all, I'm sorry for the late reply.
And thank you for the suggestion.

Most of the NAND flash devices and HDDs have wear leveling and bad sector replacement algorithms applied.
So I think that the life of the boot sector will not be exhausted first.

Currently the volume dirty/clean policy of exfat-fs is not perfect,
but I think it behaves similarly to the policy of MS Windows.

Therefore,
I think code improvements should be made to reduce volume flag records while maintaining the current policy.

BR
Sungjong Seo
> 
> 
> BR
> ---
> Tetsuhiro Kohada <kohada.t2@...il.com>

Powered by blists - more mailing lists