Hi folks, I've just got my iscsi test systems back up and running and I'm seeing tests generic/43[014] all getting stuck in the same way. xfs_io is hard looping and not making progress, and the strace output looks like this: ..... copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 copy_file_range(4, [1000], 3, [0], 100, 0) = 0 ..... I can kill the xfs_io process and the test then fails and moves on to the next, so it appears there's a problem with the copy_file_range() implementation. On the same kernel (4.14-rc2) but different devices (local SSD, ram disk or pmem) there is no problems being reported by these tests and they complete extremely quickly. It's clearly not related to XFS's reflink mkfs option, because I can reproduce it on filesystems without that option enabled. And I just reproduced it on an ext4 filesystem, too, so this implies it is probably an iscsi copy offload bug. Is anyone else running xfstests on iscsi devices, and if so, are they seeing these problems? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
