这是一个创建于 1806 天前的主题，其中的信息可能已经有所发展或是发生改变。
环境：
openSUSE Leap 15.1
KDE 桌面
有几个视频要拷到 U 盘里
GUI 下：刚拖进去速度吓人，有 500MB/s，随后不断迅速下降，到 0B/s 就不动了。
终端下：用 Rsync 复制，复制了一会显示write error: Broken pipe
确认不是 U 盘或读卡器问题，我身边的设备全试过了，都有此现象
希望结果：
显示真实速度，不要一会高的吓人，一会没速度
先提前感谢！
 |
1
nightwitch 2019-12-15 11:27:35 +08:00
pv 命令了解一下，带进度条
或者用简单的 cp 命令试一下 |
 |
2
Songxwn 2019-12-15 11:31:31 +08:00
额，fedora 欢迎你
|
 |
3
love 2019-12-15 11:34:01 +08:00  1
似乎和我的问题类似
不知道是不是我的电脑问题，我特么二台电脑都是一个问题，同一电脑装 windows 正常，装 linux 复制 U 盘拷东西太多就会出错，表现在不能拷得太快，比如之前我要拷几百个 mp3 到 U 盘，一下子拷一定会中间出错，我不得已自己写了个小脚本拷几首休息 5 秒，这才能顺利拷完。。。 而用移动硬盘就没这人问题。 |
|
4
love 2019-12-15 11:36:48 +08:00
奇特的是我 Google 了没找到类似问题，不知道是不是我人品太爆自己的二台电脑或 U 盘都中招
|
 |
5
Osk 2019-12-15 11:41:10 +08:00 via Android
dmesg 有相关错误没？
|
 |
6
masker0817 2019-12-15 12:31:42 +08:00 via Android
@love 是同一个 U 盘吗？
|
|
7
love 2019-12-15 12:40:23 +08:00 via Android
@masker0817 所有 U 盘都一样
|
|
8
love 2019-12-15 12:41:42 +08:00 via Android 1
@masker0817 对了，只有一个是例外，就是十多年前的银行送的一个 1g 的 U 盘，那个盘怎么考都不会有问题
|
 |
9
KentY 2019-12-15 17:41:53 +08:00 via iPhone 1
是不是只有 Usb3 设备或 usb3 接口有此问题？
|
 |
10
input2output OP @KentY #9 我都插在 3.0 口上的，估计是这样
|
|
11
input2output OP @KentY #9 我以前同样环境，但电脑只有 2.0 口的，从来没有这个状况
|
|
12
KentY 2019-12-15 17:48:14 +08:00 via iPhone 1
@input2output 机器有 2.0 吗？插上试试，看是否帮助发现具体问题
|
 |
13
realpg 2019-12-15 18:03:29 +08:00 1
亲，这就是真实速度……
带缓存的 U 盘…… |
|
14
realpg 2019-12-15 18:04:52 +08:00 1
|
|
15
realpg 2019-12-15 18:11:37 +08:00 4
原因 TLC 相关技术
2017 年以后大厂 U 盘都开始这么搞了 SANDISK 为代表 在这之前 MLC U 盘为主 为什么这么搞？因为这种都是打着 USB3.0 高速 U 盘为卖点。实际上裸 TLC U 盘的持续写入速度也就 10~25MB/s。卖你的高速 USB 3.0 U 盘写入速度只有 15MB/s 怎么忽悠你？你能干么 尤其是 sandisk 一大堆 CZ 多少的 从 MLC 改为 TLC 不改型号的 所以 SSD 缓存技术成熟后 U 盘也跟着来了 在 windows 上，成熟的 windows 文件系统和缓存机制，对于 U 盘速度突降的适应能力很强。实际表现就是飞速拷入一段时间开始掉速，但是不会卡住。 linux 根本就不适合作桌面，他的文件系统和缓存机制貌似对这种处理非常不好，甚至会直接死机！没错，死机。有些写入速度遇到坏扇区慢死的机械硬盘时代就有这个问题。 为什么这种问题只会在 USB3.0 出现呢？因为 USB3.0 的接口速度很大，而同一个 U 盘插入 USB2.0 接口，主要受限于 USB2.0 的接口速度和主控 USB2.0 模式下的处理速度，所以，即使有 25MB/s 的比较快的 TLC，实际缓存耗尽很漫长，而且耗尽缓存后两者速率下降也不会很快，内部缓存还会释放…… 解决方案就是，现在别再买大厂的 USB3.0 的 U 盘了，搜 IS903 买 SLC 的手工制作吧…… |
|
16
KentY 2019-12-15 18:11:41 +08:00 via iPhone 1
@love
@input2output 有可能是 uas 的问题，在机器的 usb3.0 上。 你们都没给出具体的问题日志，硬件输出，内核版本只能猜。 可以试一下在 usa 模块 blacklist 你的那个 port，然后再 update-initramfs 如果没帮助可以 undo 所做的。 |
|
18
love 2019-12-15 18:22:05 +08:00 1
@realpg 和 TLC 无关吧，我用了十来年 linux 桌面爽得很，除了这个问题没有别的文件系统问题，机器上的 TLC SSD 也有二块也没这问题
|
|
19
input2output OP @KentY #16
USB2.0 好像同样问题，挺奇怪的，以前好像没有过 |
|
20
KentY 2019-12-15 18:32:18 +08:00 via iPhone 1
@input2output my resource ends
|
 |
21
superrichman 2019-12-15 18:45:28 +08:00
你用 windows 拷贝同样的文件看看，这锅可能不是 linux 系统的问题
|
 |
22
jin7 2019-12-15 19:24:05 +08:00
听说是 bug 我现在担心数据的完整性(usb 传输)
|
|
23
input2output OP @jin7 #22 视频文件我都打开看看，重要文件我都要算个 SHA1
|
|
24
jin7 2019-12-15 19:33:05 +08:00
@input2output 我用 windows 备份的数据倒是不担心 主要是担心 linux 下面用 rsync 同步的数据
都是 usb3.0 普通移动硬盘 |
 |
25
toptyloo 2019-12-15 20:12:54 +08:00
如果是上面说的仅存在于 USB 3.0 的问题，那就把 U 盘缓慢插入 USB 口，使机器识别成 USB2.0 试试？
|
 |
26
jasonyang9 2019-12-15 21:14:37 +08:00
LZ 试试 rsync 限速开关用上还会有这种问题？
--bwlimit= |
 |
27
bandian 2019-12-15 22:26:43 +08:00
manjaro + kde 下从 dolphin 直接把文件拖到 U 盘的时候会出现一开始速度很快，然后突然降速的情况。
用 cp 的时候感觉没啥问题。 不过我觉得可能是因为 cp 一般没有进度条吧 |
 |
28
lzwt806 2019-12-15 23:05:21 +08:00 2
楼主是问题见这里： http://kxs-co.gicp.net/linux/CDLinux.html
以下选取： 5，一个所有 Linux 发行版都有的不是 BUG 的 BUG Linux 当初设计文件的读写时思想是：当用户复制 /剪切 /移动一个文件表面看起来瞬间就完成了，等待一定的时间如果用户不再操作时再在后台完成余下的工作，这样可以有效的避免产生大量的磁盘碎片，但因此带来的害处远远大于益处，如果应用场合是本地硬盘还算好，若使用的是移动存储设备就可能产生意外，结果就是使用外置存储设备时及易因误判断而损坏文件（两边的文件均是损坏的），从表象上看就是操作时的反馈进度信息不同步 实验过程：在 KDE/XFCE/LXDE 下复制一个 500M 的文件到 U 盘，看着进度条走完就拔出 U 盘，试试 U 盘里的文件是否是正常的？ 解决办法：A，操作完成后多等会（ 10 分钟？）。B，看着 U 盘的灯不再闪后才拔盘。C，在文件管理器里面弹出 U 盘，且提示成功才拔盘 危害等及：非常严重，对于不知情或心急的人，极易把文件损坏，后果严重，业界确对这种低级的设计视而不理 可修复性：难度大，曾和老赵商讨过此事，内核并不知道文件操作完没，因为对文件的操作很多文件管理器可以跳过内核直接对文件进行操作，整个反馈均在应用层，所以这是由 DE 引起的。在 CDLinux 的 xfce 环境里，曾试着解决这个问题，最开始是强制同步，每次写入后就同步到进度条，结果发现这样及易损坏存储设备（在测试中把一张 16G 的威刚内存卡写成了只读），后来改为不强制同步但尽量多次同步进度条，虽有改善但并不完美，与 Windows 的实时进度条相比，天差地别。 我只想对这种设计思维的人说一句：简直就是狗屎一样的设计！ |
 |
29
electriccubes 2019-12-15 23:17:17 +08:00 via Android
@lzwt806 毕竟这操作诞生在移动储存很少的年代，而且 win7 及以前也会这样，只是不这样激进罢了
|
 |
30
crella 2019-12-15 23:21:53 +08:00 via Android
@lzwt806 是的，想起 gnome 和 kde 都有挂自己管理 io 的进程……不过之前以为仅仅是调用内核 api
|
 |
31
wwhc 2019-12-16 00:48:13 +08:00
dstat 显示真实的实时速度
|
 |
32
wiewiewie 2019-12-16 10:08:20 +08:00
我的帖子里 提过用 PV+ NC 开端口复制 你参考。
|
|
33
input2output OP |
|
34
realpg 2019-12-18 23:47:38 +08:00
@input2output #33
客气 这个应该不算啥优化不到位 应该是设计的时候就没考虑过这种问题 早年没有 SSD 没有 FLASH 的时代，面对一些硬盘坏道导致的部分扇区并不是完全不可读写，只是读写速度巨慢无比的突发就会有这个问题，当时 ext3 就很严重，对读写速度大幅度波动会出问题，甚至直接死机，而不是只死个进程啥的 其实 windows 也会有这种问题导致写入线程卡住，只是 EXPLORER 不会完全死掉，会自己慢慢恢复过来，而在 linux 下基本就不会。 |
Select Language