将文件复制到Pendrive时，为什么PC冻结？

我在这里有一个非常奇怪的情况。我的PC至少在大多数情况下都可以正常工作，但是有一件事我无法处理。当我尝试从笔式驱动器中复制文件时，一切正常-我的速度为16-19M / s，效果很好。但是，当我尝试将某些内容复制到同一笔驱动器时，我的PC冻结了。鼠标指针停止移动一两秒，然后再移动一点，然后再次停止。例如，在Amarok中播放声音时，声音就像机关枪一样。速度从500K / s跃升至15M / s，平均8M / s。仅当我将某些内容复制到Pendrive时才会发生这种情况。复制过程完成后，一切恢复正常。

我尝试了所有方法-其他pendrive，前面板上的其他USB端口或后面板上的那些端口，我什至更改了主板（前面板）上的USB引脚，但是无论我将USB随身碟放在哪里，都总是一样。我尝试不同的文件系统- ，。fat32 ext4我的笔记本电脑上的Windows设备没有问题。它必须是我的PC或系统中的东西。我不知道该找什么。我正在使用带有独立Openbox的Debian测试。我的PC很旧-Pentium D 3GHz，1GiB RAM，1,5TB WD Green磁盘。如果您有什么可以帮助我解决此问题的信息，我将很高兴听到。

我不知道我还应该提供什么信息，但是如果您需要什么，请问一下，我会尽快更新。

我试图在ubuntu 13.04 live cd上重现此问题。我安装了加密分区+加密交换，并将笔式驱动器连接到USB端口。接下来，我尝试启动一些应用程序，现在RAM中有〜820MiB，在SWAP中有大约400MiB。复制没有问题，完全没有冻结，一切都应该达到目的。因此，看起来这是系统的故障，但究竟在哪里呢？什么会导致这种奇怪的行为？

您是否正在使用具有大量内存的64位版本的Linux？在那种情况下，问题可能在于Linux可以锁定SD卡或USB记忆棒等慢速设备上的大量写入操作几分钟。这是一个已知的错误，应该在较新的内核中修复。

参见http://lwn.net/Articles/572911/

解决方法：作为根本问题：

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

我已将其添加到/etc/rc.local我的64位计算机中的文件中。

丹斯塔夫 ; 这项更改可以（可能会）减少这些设备的吞吐量-这是延迟和速度之间的折衷方案。要恢复以前的行为，您可以

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

...是默认值，这意味着写回行为将由参数dirty_ratio和来控制dirty_background_ratio。

请那些不太熟悉Linux的人注意：其中的文件/proc 是伪文件-只是内核和用户空间之间的通信通道。切勿使用编辑器来更改或查看它们；取而代之的是shell提示---例如，使用sudo -i（Ubuntu风格）或su root和使用echoand cat。

更新2016/04/18似乎毕竟问题仍然存在。你可以看一下它在LWN.net，在这篇关于写回队列。

原因可能是写放大，因为系统尝试以小于擦除块（执行读/修改/写）+块未对齐的小块写入。

要检查您当前的设置，请执行以下操作：

cat /sys/block/sd**X**/device/max_sectors

您可以调整这些设备的大厅规则：

更改整个设备系列的USB“ max_sectors”的值

在这种情况下，我已将所有设备的max_sectors替换为使用默认值240（USB存储）的32K扇区或2K扇区。

在我的系统（Mageia 4，3.14.24核心i7）上，由于在Kingston DT101 G2 16GB上的写入速度非常慢（2MB /秒），所以我必须这样做：

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

并添加：

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

而dd写入速度上升了3倍的时间。mc cp可能增加了10到20倍（在我开始对第8192个扇区进行第一个分区并用64k对齐的簇重新格式化后）：

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

检查对齐（检查[数据起始扇区]应该是128的倍数（群集大小））。如果需要，调整保留扇区的数量（-R）。

默认的max_sectors（240）似乎在某些廉价的新驱动器上导致高写入放大率。但是请注意，在如此高的设置下，在2048个扇区（可能是1M擦除块）上会达到类似的效果：

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

测试您所有的旧USB设备，使其仍然可以正常工作。使用规则文件中的供应商/模型属性来更具体。

硬件与软件

我遇到了一个与USB拇指驱动器类似的奇怪问题，在我的研究中，几乎总是驱动程序问题或PC /主板中的特定硬件。

我知道这一点是因为我有几个系统都是相同的硬件，而在一个系统上，我可以毫无问题地执行此操作，而在另一个系统上，则可以看到问题。

该怎么办？

您的选择在这里确实很有限。关于您唯一可以做的就是确保您的系统上安装了最新的BIOS /固件，并确保您拥有disto软件包的最新版本。

除了我能提供的建议之外，请确保不通过在进行另一个副本时尝试复制文件来避免这种情况。

如果您的性格会让您感到类似，那么您可以尝试另一个Linux实时发行版，然后重复导致问题的步骤。如上所述，这只会消除是发行版特定问题还是硬件问题。这将是一个小小的安慰，但是我总是喜欢了解一些事情，而不是把我的头埋在沙子里，而不是。

还要别的吗？

如果您真的很着迷，可以尝试运行正在执行复制操作的应用程序，以strace期在任何冻结的系统调用中捕获系统。您也应该能够从命令行执行此操作。

例

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

然后在运行时启动另一个。

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

该系统有望在此操作期间冻结，并且也许您会很幸运，并在其中任何一个日志文件中发现一些冒烟。