Possibly we need to pick up some more patches or some code section from
your experimental branch for the read/write.
On 11/8/21 10:10 PM, 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 ?
Thanks.
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(-)
