https://bugzilla.suse.com/show_bug.cgi?id=1224434
https://bugzilla.suse.com/show_bug.cgi?id=1224434#c1
Jan Kara changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fdmanana@suse.com
--- Comment #1 from Jan Kara ---
Since this is on btrfs, we should involve someone from btrfs team. Filipe, can
you have a look? Feel free to reassign if somebody else is a better fit.
Checking the kernel logs I agree the iomap code is complaining about failure to
invalide page cache *after* a direct write. I can also see LTP is declaring the
test as broken because fsync(2) after writing the file has failed with EIO:
tst_test.c:1734: TINFO: LTP version: 20240524
tst_test.c:1618: TINFO: Timeout per run is 0h 30m 30s
aiocp.c:211: TINFO: Maximum AIO blocks: 65536
tst_device.c:545: TINFO: Use BTRFS specific strategy
aiocp.c:250: TINFO: Fill srcfile.bin with random data
aiocp.c:279: TINFO: Copy srcfile.bin -> dstfile.bin
aiocp.c:115: TBROK: fsync(4) failed: EIO (5)
And this is weird because it shouldn't be caused by the page cache
invalidation.
Now I suspect this is connected with the fact that PowerPC64 where this is
happening has page size of 64k and so all the failing cases are not page
aligned and so individual IOs are going to use the same page and if we fall
back to buffered IO for some reason, conflicts between buffered and direct IO
can happen. But since this is not happening with SLE15-SP6, something must have
changed.
--
You are receiving this mail because:
You are on the CC list for the bug.
