From: David Howells <dhowells@redhat.com>
To: fstests@vger.kernel.org, darrick.wong@oracle.com
Cc: dhowells@redhat.com, Steve French <sfrench@samba.org>,
linux-cifs@vger.kernel.org
Subject: generic/304 doesn't seem terminable for cifs
Date: Sat, 02 Dec 2023 22:14:20 +0000 [thread overview]
Message-ID: <3876191.1701555260@warthog.procyon.org.uk> (raw)
I've been running "-g quick" on a CIFS mount and it got to generic/304... and
is still there nearly 30 hours later. The kernel isn't stuck - userspace is
cranking out BTRFS_IOC_FILE_EXTENT_SAME or FIDEDUPERANGE at a great rate.
The ps tree looks like:
S+ 0:03 \_ /bin/bash ./check -E .exclude -g quick
S+ 0:00 \_ /bin/bash /root/xfstests-dev/tests/generic/304
S+ 0:00 \_ /bin/bash /root/xfstests-dev/tests/generic/304
Dl+ 316:55 | \_ /usr/sbin/xfs_io -i -f -c dedupe /xfstest.test/test-304/file0 0 0 9223372036854775807 /xfstest.test/test-
S+ 0:00 \_ /bin/bash /root/xfstests-dev/tests/generic/304
S+ 0:00 \_ sed -e s/^dedupe:/XFS_IOC_FILE_EXTENT_SAME:/g
The xfs_io command strace is an endlessly repeated:
ioctl(4, BTRFS_IOC_FILE_EXTENT_SAME or FIDEDUPERANGE, {src_offset=389438053887770624, src_length=8833933982967005183, dest_count=1, info=[{dest_fd=3, dest_offset=389438053887770624}]} => {info=[{bytes_deduped=1073741824, status=0}]}) = 0
ioctl(4, BTRFS_IOC_FILE_EXTENT_SAME or FIDEDUPERANGE, {src_offset=389438054961512448, src_length=8833933981893263359, dest_count=1, info=[{dest_fd=3, dest_offset=389438054961512448}]} => {info=[{bytes_deduped=1073741824, status=0}]}) = 0
ioctl(4, BTRFS_IOC_FILE_EXTENT_SAME or FIDEDUPERANGE, {src_offset=389438056035254272, src_length=8833933980819521535, dest_count=1, info=[{dest_fd=3, dest_offset=389438056035254272}]} => {info=[{bytes_deduped=1073741824, status=0}]}) = 0
ioctl(4, BTRFS_IOC_FILE_EXTENT_SAME or FIDEDUPERANGE, {src_offset=389438057108996096, src_length=8833933979745779711, dest_count=1, info=[{dest_fd=3, dest_offset=389438057108996096}]}^Cstrace: Process 105030 detache
with the dest_offset increasing a bit each time. The log so far is:
wrote 1/1 bytes at offset 9223372036854775806
1.000000 bytes, 1 ops; 0.0000 sec (97.656 KiB/sec and 100000.0000 ops/sec)
wrote 1/1 bytes at offset 9223372036854775806
1.000000 bytes, 1 ops; 0.0000 sec (97.656 KiB/sec and 100000.0000 ops/sec)
wrote 1/1 bytes at offset 1048575
1.000000 bytes, 1 ops; 0.0000 sec (139.509 KiB/sec and 142857.1429 ops/sec)
Looking in the protocol dump, it's endlessly repeating:
190 0.007930488 192.168.6.2 → 192.168.6.1 SMB2 174 SetInfo Request FILE_INFO/SMB2_FILE_ENDOFFILE_INFO
191 0.007962785 192.168.6.1 → 192.168.6.2 SMB2 136 SetInfo Response
192 0.007974644 192.168.6.2 → 192.168.6.1 SMB2 230 Ioctl Request FILE_SYSTEM Function:0x00d1
193 0.008069283 192.168.6.1 → 192.168.6.2 SMB2 182 Ioctl Response FILE_SYSTEM Function:0x00d1
It's advancing the EOF marker each time and then doing some ioctl function
that wireshark can't decode.
Is this a bug in "xfs_io dedupe"?
David
next reply other threads:[~2023-12-02 22:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-02 22:14 David Howells [this message]
2023-12-04 0:00 ` generic/304 doesn't seem terminable for cifs Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3876191.1701555260@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox