Linux 文件复制遇到的问题，求助！

你用 windows 拷贝同样的文件看看，这锅可能不是 linux 系统的问题

听说是 bug 我现在担心数据的完整性(usb 传输)

@jin7 #22 视频文件我都打开看看，重要文件我都要算个 SHA1

@input2output 我用 windows 备份的数据倒是不担心 主要是担心 linux 下面用 rsync 同步的数据
都是 usb3.0 普通移动硬盘

如果是上面说的仅存在于 USB 3.0 的问题，那就把 U 盘缓慢插入 USB 口，使机器识别成 USB2.0 试试？

LZ 试试 rsync 限速开关用上还会有这种问题？

--bwlimit=

manjaro + kde 下从 dolphin 直接把文件拖到 U 盘的时候会出现一开始速度很快，然后突然降速的情况。
用 cp 的时候感觉没啥问题。
不过我觉得可能是因为 cp 一般没有进度条吧

楼主是问题见这里： 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 的实时进度条相比，天差地别。
我只想对这种设计思维的人说一句：简直就是狗屎一样的设计！

@lzwt806 毕竟这操作诞生在移动储存很少的年代，而且 win7 及以前也会这样，只是不这样激进罢了

@lzwt806 是的，想起 gnome 和 kde 都有挂自己管理 io 的进程……不过之前以为仅仅是调用内核 api

dstat 显示真实的实时速度

我的帖子里 提过用 PV+ NC 开端口复制 你参考。

@realpg #15
朋友那边借了个 SLC 芯片的无缓存 U 盘，速度确实稳了（第一次用 SLC U 盘，被速度吓到了）
感谢老哥，看来 Linux 还是优化不到位啊

@input2output #33
客气 这个应该不算啥优化不到位
应该是设计的时候就没考虑过这种问题

早年没有 SSD 没有 FLASH 的时代，面对一些硬盘坏道导致的部分扇区并不是完全不可读写，只是读写速度巨慢无比的突发就会有这个问题，当时 ext3 就很严重，对读写速度大幅度波动会出问题，甚至直接死机，而不是只死个进程啥的

其实 windows 也会有这种问题导致写入线程卡住，只是 EXPLORER 不会完全死掉，会自己慢慢恢复过来，而在 linux 下基本就不会。