Re: pkg/46529: ntfs-3g appears to be rate-limited

["Aaron J. Grier via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/46529; it has been noted by GNATS.

From: "Aaron J. Grier" <agrier%poofygoof.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/46529: ntfs-3g appears to be rate-limited
Date: Tue, 5 May 2026 20:07:41 -0700

 dusting this one off; I technically still have the drive and system
 originally tested, but if the hypothesis is that fuse-ntfs-3g (or
 something in the puffs / fuse pipeline) is the rate limit, the issue
 should also show up in a different configuration.
 
 test is moved to NetBSD-11 running under KVM VM.
 
 raw (virtual) disk speed:
 cratylus$ sudo dd if=/dev/ld0e of=/dev/null bs=64k count=40000
 40000+0 records in
 40000+0 records out
 2621440000 bytes transferred in 17.449 secs (150234397 bytes/sec)
 
 and after bumping up kern.sbmax so librefuse can setsockopt() its
 buffers for 16 * FUSE_BUFSIZE, I get the following from a large file on
 a ntfs-3g fuse mount:
 
 cratylus$ dd if=bigfile1 of=/dev/null bs=64k
 7187+1 records in
 7187+1 records out
 471026263 bytes transferred in 6.603 secs (71335190 bytes/sec)
 cratylus$ dd if=bigfile2  of=/dev/null bs=64k
 11204+1 records in
 11204+1 records out
 734328832 bytes transferred in 10.439 secs (70344748 bytes/sec)
 
 I'd say that definitively demonstrates the problem isn't with
 fuse-ntfs-3g or the NetBSD library and kernel side of things for
 NetBSD-11, so this can be closed.
 
 I'm half wondering if the problem is in the USB stack, or if the buffer
 size for the perfuse unix domain socket was an issue in the past, but if
 I find anything later it's easy enough to submit another bug.
 
 thanks for renewing the reminder emails from gnats; I'm sure a lot of
 them get bit-bucketed, but they were the push I needed to wrap this one
 up.