为什么我的桌面锁定当我复制很多文件到一个USB驱动器？

Question

我的桌面通常响应性很强，即使在很重的负载下也是如此。但是当我把文件拷贝到USB驱动器时，它总是会在一段时间后被锁上。“锁起来”，我的意思是：

• 将焦点从一个窗口移到另一个窗口需要10到20分钟。
• 转换台式机可能需要10-20秒。
• 视频不再更新(在YouTube中，音频继续播放，只有视频冻结)

当这种情况发生时，系统负载并不特别高。有时，我在xosview上看到很多白色，表明内核在某个地方很忙。

乍一看，似乎将文件复制到USB驱动器会以某种方式干扰compiz，但我无法想象连接会是什么。

下面是htop的输出：

下面是iostat -c -z -t -x -d 1在2分钟挂起期间的输出：

19.07.2012 20:38:22
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,27    0,00    0,38   37,52    0,00   60,84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdg               0,00     2,00    0,00  216,00     0,00 109248,00  1011,56   247,75  677,69    0,00  677,69   4,63 100,00

如您所见，只有外部硬盘处于活动状态。以下是完整的日志：http://pastebin.com/YNWTAkh4

挂牌开始于20:38:01，结束于20:40:19。

软件信息：

• openSUSE 12.1
• KDE 4.7.x
• 文件系统:我的内部硬盘上有reiserfs和btrfs，USB驱动器上有btrfs。

Answer 1

我的第一个猜测是btrfs，因为这个文件系统的I/O进程有时会接管。但这也解释不了为什么X会锁起来。

看看这些干扰，我看到了这个：

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        179          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    3306384          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1

好吧，呃。USB驱动程序使用与图形卡相同的IRQ，它是链中的第一位。如果它被锁定(因为文件系统做了一些昂贵的事情)，显卡就会挨饿(网络也是如此)。

Answer 2

我曾在openSUSE 12.1's Linux3.1内核中看到类似的问题，并发现禁用透明的巨大页面有助于：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

潜在的问题是，如果应用程序分配了4MB或更多的内存，内核将尝试给它一个巨大的页面，为此它需要一个完整的连续4MB RAM。现在，如果周围有许多脏页，仍然需要写入一个缓慢的USB设备，它会等待IO完成，然后再继续内存分配。

Answer 3

如前所述，这可能与内核hugepages设置有关。我认识几个有这个问题的人。你可以在网上找到一些关于它的文档。

• https://bbs.archlinux.org/viewtopic.php?id=112846&p=1
• http://lwn.net/Articles/467328/
• http://forum.manjaro.org/index.php?topic=2062.0
• 在将文件复制到设备或从USB设备复制文件时，性能缓慢。

通过执行以下操作，我已经完全解决了我的设置上的问题。注意YMMV，并不是所有的修复都是必要的，也许它们是不够的。我可能忘了一些诚实的东西。不管怎么说，这是我的安排，而且很有效。

• 使用linux-ck内核
• echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
• echo never > /sys/kernel/mm/transparent_hugepage/defrag