On Thu, Feb 04, 2021 at 03:59:52PM +0800, Sun Ke wrote:
> Hi, Zorro
>
> 在 2021/2/3 0:05, Zorro Lang 写道:
> > On Tue, Feb 02, 2021 at 08:39:56PM +0800, Sun Ke wrote:
> > > Fill the disk space, try to create some files and rename a file, mount
> > > again, list directory contents and triggers some errors. It is a
> > > regression test for kernel commit 6b4b8e6b4ad8 ("ext4: ext4: fix bug for
> > > rename with RENAME_WHITEOUT")
> > >
> > > Signed-off-by: Sun Ke <sunke32@xxxxxxxxxx>
> > > ---
> > > v3: use _check_dmesg_for() and modify the group.
> > > ---
> > I helped to re-write this case(without loopdev, dmesg check and ext4 specific
> > things) as below[1]. It can reproduce that bug[2], and test passed on fixed
> > kernel[3].
> Thanks for your help. Yes, it can reproduce the bug on ext4 test.
> >
> > But I found another problem, we can't 100% make sure that renameat2 hit ENOSPC,
> > even if we can't create any empty file. That renameat2 line still succeed on
> > my XFS test. And Eric Sandeen even can't trigger that rename ENOSPC on his
> > machine.
>
> The same as Eric, I can not trigger that rename ENOSPC on my machine on
> xfs test.
No, I mean that rename not always hit ENOSPC on ext4 either. Due to that way
to fill filesystem can't make sure there's not space to do once
rename(RENAME_WHITEOUT).
But even if we can't make sure the ENOSPC 100%, I think high probability is
acceptable. So I asked if we can test a chunk of files (not only test
a single one file) in my last email[1], hope to get some suggestions from
fs experts.
[1]
https://marc.info/?l=linux-xfs&m=161233233321478&w=2
Thanks,
Zorro
>
> Thanks,
>
> Sun Ke
>
>
> > .
>
