https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244356
--- Comment #20 from Sebastien Boisvert <s...@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 disk
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 order
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 that is
used for write operations ?
I mean, if userspace does not call "sync", then the data can be dirty in kernel
space without being written back to the device. That usually makes I/O faster.
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_EXIT
in FreeBSD ?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
