NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/46529: ntfs-3g appears to be rate-limited
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: Wed, 6 May 2026 11:40:05 -0700
you are absolutely correct, the baseline is all zfs cache behavior on
the backing side, and doesn't represent actual disk I/O.
looking on the back-end I see zvol iostat showing ~120MB/s but no
activity on the disks in the array, and no blinking lights on the drives
themselves. since the disk image is on a sparse (and compressed) ZFS
volume, this has to be expected.
I disabled my swap wedge and dding from it generated actual disk
activity, but since the backing store is sparse, as soon as reads moved
past the small amount of existing swap data, sparse handling kicked in
and the rest of the wedge data was fulfulled without any disk I/O.
I don't have an easy way to get actual USB passthrough on the system (it
lives in a rack and has no easy-access USB ports), so I'm not sure how
to get a good baseline out of this.
here's an iostat snippet from the NetBSD side while reading through ntfs-3g:
device read KB/t r/s time MB/s write KB/t w/s time MB/s
ld0 2.00 38431 0.58 75.06 0.00 0 0.58 0.00
ld0 2.00 34170 0.69 66.74 0.00 0 0.69 0.00
ld0 2.00 37623 0.70 73.48 0.00 0 0.70 0.00
ld0 2.00 34487 0.79 67.36 0.00 0 0.79 0.00
ld0 2.00 35610 0.87 69.55 0.00 0 0.87 0.00
ld0 2.00 39171 0.70 76.51 0.00 0 0.70 0.00
ld0 2.00 35614 0.81 69.56 0.00 0 0.81 0.00
ld0 2.00 38249 0.71 74.70 0.00 0 0.71 0.00
ld0 2.00 40597 0.52 79.29 0.00 0 0.52 0.00
ld0 2.00 36121 0.79 70.55 0.00 0 0.79 0.00
the VM back-end is all cached at this point, but it's not NetBSD's
buffercache.
the original problem was that ntfs-3g was slow, which I'm definitely no longer
observing. I'm satisifed now, and feel like I'm beating a dead horse at this
point, given the original ticket was filed in 2012.
ready to close this one if you are.
Home |
Main Index |
Thread Index |
Old Index