[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <500801d64572$0bdd2940$23977bc0$@samsung.com>
Date: Thu, 18 Jun 2020 22:11:58 +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
> > Since this patch does not resolve 'VOL_DIRTY in ENOTEMPTY' problem you
> > mentioned, it would be better to remove the description above for that
> > and to make new patch.
>
> I mentioned rmdir as an example.
> However, this problem is not only with rmdirs.
> VOL_DIRTY remains when some functions abort with an error.
> In original, VOL_DIRTY is not cleared even if performe 'sync'.
> With this patch, it ensures that VOL_DIRTY will be cleared by 'sync'.
>
> Is my description insufficient?
I understood what you said. However, it is a natural result
when deleting the related code with EXFAT_SB_DIRTY flag.
So I thought it would be better to separate it into new problems
related to VOL_DIRTY-set under not real errors.
>
>
> 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.
Thanks.
>
>
> BR
> ---
> Tetsuhiro Kohada <kohada.t2@...il.com>
>
>
Powered by blists - more mailing lists