On Mon, 2021-11-08 at 22:10 +0800, Xiubo Li wrote: > Hi Jeff, > > After this fixing, there still has one bug and I am still looking at it: > > [root@lxbceph1 xfstests]# ./check generic/075 > FSTYP -- ceph > PLATFORM -- Linux/x86_64 lxbceph1 5.15.0-rc6+ > > generic/075 [failed, exit status 1] - output mismatch (see > /mnt/kcephfs/xfstests/results//generic/075.out.bad) > --- tests/generic/075.out 2021-11-08 20:54:07.456980801 +0800 > +++ /mnt/kcephfs/xfstests/results//generic/075.out.bad 2021-11-08 > 21:20:49.741906997 +0800 > @@ -12,7 +12,4 @@ > ----------------------------------------------- > fsx.2 : -d -N numops -l filelen -S 0 > ----------------------------------------------- > - > ------------------------------------------------ > -fsx.3 : -d -N numops -l filelen -S 0 -x > ------------------------------------------------ > ... > (Run 'diff -u tests/generic/075.out > /mnt/kcephfs/xfstests/results//generic/075.out.bad' to see the entire diff) > Ran: generic/075 > Failures: generic/075 > Failed 1 of 1 tests > > > I checked the result outputs, it seems when truncating the size to a > smaller sizeA and then to a bigger sizeB again, in theory those contents > between sizeA and sizeB should be zeroed, but it didn't. > > The last block updating is correct. > > Any idea ? > Yep, that's the one I saw (intermittently) too. I also saw some failures around generic/029 and generic/030 that may be related. I haven't dug down as far into the problem as you have though. The nice thing about fsx is that it gives you a lot of info about what it does. There is also a way to replay a series of ops too, so you may want to try to see if you can make a reliable reproducer for this problem. Are these truncates running concurrently in different tasks? If so, then we may need some mechanism to ensure that they are serialized vs. one another. > > On 11/8/21 9:50 PM, xiubli@xxxxxxxxxx wrote: > > From: Xiubo Li <xiubli@xxxxxxxxxx> > > > > Hi Jeff, > > > > The #1 could be squashed to the previous "ceph: add truncate size handling support for fscrypt" commit. > > The #2 could be squashed to the previous "ceph: fscrypt_file field handling in MClientRequest messages" commit. > > > > Thanks. > > > > Xiubo Li (2): > > ceph: fix possible crash and data corrupt bugs > > ceph: there is no need to round up the sizes when new size is 0 > > > > fs/ceph/inode.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > -- Jeff Layton <jlayton@xxxxxxxxxx>
