Hello,
I can reproduce this on Noble and Oracular on the Ubuntu GNOME desktop.
While it is true that the copy jumps "too fast", it blocks at 99% in the
file manager and will not say it is done while the real copy happens. So
it is not that bad in my opinion.
Same thing with `pv` on Noble which indicates huge, wrong transfer speed
over USB2 and then hangs while the transfer completes:
$ head -c 1G /dev/random > big-noble.bin
$ pv big-noble.bin > /media/me/usbkey/big.bin
1.00GiB 0:00:01 [ 820MiB/s] [==============================================>]
100%
Since the programs wait for the write to complete and do not seem to
require a `sync` or `unmount` call to complete like it was the case few
years ago, I consider this acceptable behavior.
As you noted this seems to be related to writeback buffer size. The
behavior is exacerbated for systems with a lot of RAM. The default
writeback buffer size might be optimized for server workloads. We do not
have a specific "desktop" kernel that could allow to lower the default
value in configuration for this usecase.
Thus, I will mark at wontfix and invite you to modify the runtime values
if needed for your usecase or compile yourself a custom "desktop" kernel
if you need the defaults changed.
Thanks.
** Changed in: linux (Ubuntu)
Status: New => Won't Fix
** Changed in: linux (Ubuntu Oracular)
Status: New => Won't Fix
** Changed in: linux (Ubuntu)
Importance: Undecided => Low
** Changed in: linux (Ubuntu Oracular)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2089058
Title:
Problems with caching and write performance on USB devices on Linux
(FAT32, NTFS, ext4)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2089058/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
