I filed the bug in kernel.org bugzilla as https://bugzilla.kernel.org/show_bug.cgi?id=215460 summary: fs/ntfs3: page_cache_ra_unbounded on rsync from ntfs3 to ext4 I hope someone is looking into this. In the below, email, I had to mention that to produce the trace as mentioned in the other emails one should load manjaro or arch live-cds * archlinux-2022.01.01-x86_64.iso (kernel-5.15.12) * manjaro-gnome-21.2.0-211220-linux515.iso (kernel-5.15.7) The bug happens if the src partition is mounted as ntfs3 on vhdx. So i believe it is triggered from the "read" side filesystem of rsync. The dst partition/filesystem can be ext4 and is on a fixed qcow2 or raw disk. Bug does not happen if src partition is mounted using ntfs-fuseblk driver. -Gana From: Ganapathi Kamath Sent: Friday, December 31, 2021 11:22 AM To: Matthew Wilcox <willy@xxxxxxxxxxxxx>; ntfs3@xxxxxxxxxxxxxxx <ntfs3@xxxxxxxxxxxxxxx> Subject: regarding: Re: Bug using new ntfs3 file system driver (5.15.2 on Arch Linux) Hello, A) Included below is I think a sure-way to reproduce the bug. (I wasn't sure if you had done reproduction yet, and were looking only at provided kernel traces) B) Is there a specific kernel-bug ## I can cite and watch for progress/fix ? I ran into the same while doing similar rsync tests related to qemu bug https://gitlab.com/qemu-project/qemu/-/issues/727 1) create empty qcow2 file [root@sirius gana]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 2) create another qcow2/vhdx containing sgdata, Ensure that data is good/not be corrupt. (I prepare my vhdx on windows) That issue filing mentioned earlier has scriptlets for "synthetic generated data" (sgdata) https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 3) download a fedora rawhide iso https://archive.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/ 4) [root@sirius gana]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20211230.n.0.iso" -hda "/mnt/a16/gkpics01.qcow2" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga-gl" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" Inside VM, open a terminal tab 1) use gdisk make type-0700 partition /dev/sda1 2) format /dev/sda1 as ntfs mkfs -t ntfs -Q -L fs_gkpics01 /dev/sda1 3) mount /dev/sda and /dev/sdb mount /dev/sda1 /mnt/a mount /dev/sdb2 /mnt/b 4) ( sdate=`date`; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rsynclog.txt ; echo $sdate ; date ) monitor dmesg -w in a second tab Basically, in the above test, I am trying to copy about 85GiB of data from /dev/sdb2 to /dev/sda1 The kernel trace happens within less than a couple of Gb of transfer, after which rsync bails out. -Gana
