Date: Sun, 01 Mar 2020 16:33:50 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 244356] Writing to a USB 3.0 stick is very slow Message-ID: <bug-244356-19105-goBszQptvP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/> References: <bug-244356-19105@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244356 --- Comment #20 from Sebastien Boisvert <seb@boisvert.info> --- (In reply to Hans Petter Selasky from comment #18) > FreeBSD doesn't have a disk cache. I don't know much about FreeBSD so maybe I am wrong, but: In FreeBSD, ZFS ARC (adaptive replacement cache) is a disk cache for read operations for ZFS. So, for read operations, if I have ZFS on the USB stick, then there is a di= sk cache for read operations through the ZFS ARC, right ? Although that there are no disk cache for write operations, FreeBSD probably has a queue (or queues) in the block subsystem for AHCI I/O operations (with SATA 3 for instance). This logical queue can be used to coalesce and/or ord= er I/O commands before draining this queue to submit to the device queue. I don't know if USB 3.0 sticks are mono-queue or multi-queue. I know that SATA has 1 queue with a depth of 32 whereas NVMe has 64k queues with each a depth of 64k. I know that Linux has a page cache (unified for the virtual memory and block devices and so on). Do you think that USB 3.0 works well on Linux because of the page cache tha= t is used for write operations ? I mean, if userspace does not call "sync", then the data can be dirty in ke= rnel space without being written back to the device. That usually makes I/O fast= er. The documentation of "select" says: "to see if some of their descriptors are ready for reading, are ready for writing" --> https://www.freebsd.org/cgi/man.cgi?select Here, select takes 60 seconds to conclude that none of the descriptors are ready. That delay is clearly abnormal. How can I trace what is being called between the select_ENTER and select_EX= IT in FreeBSD ? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244356-19105-goBszQptvP>