Thank you for your reply.
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.
I'm not too worried about the life of the boot-sector.
I'm worried about write failure
> Thanks for thinking on this complicated issue.
>
>
> > 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.
>
> I'm not too worried about the life of the boo
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
> 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 erro
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 j
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 insuffi
> > 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 funct
Thank you for your comment.
On 2020/06/17 16:20, 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_filesyst
> > 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.
>
> 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
> 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_
On Tue, Jun 16, 2020 at 08:16:55AM +0200, Markus Elfring wrote:
> > remove EXFAT_SB_DIRTY flag and related codes.
>
> I propose to omit this sentence because a similar information
> is provided a bit later again for this change description.
Please stop.
> remove EXFAT_SB_DIRTY flag and related codes.
I propose to omit this sentence because a similar information
is provided a bit later again for this change description.
> If performe 'sync' in this state, VOL_DIRTY will not be cleared.
Please improve this wording.
Do you care to avoid a typo he
13 matches
Mail list logo
