拷贝大文件（并且数量多）到移动硬盘的过程中经常死机

看样子是linux的file cache的问题，你可以按照下面的说明试试。
http://askubuntu.com/questions/122857/can-i-copy-large-files-faster-without-using-the-file-cache

如果这个不好用，可以尝试找找linux下的kernel-bypass的拷贝命令，具体我忘记了，我记得是有类似的工具。主要就是减少用户态内存和内核态内存的数据拷贝。

如果系统的硬盘与资料的硬盘分开呢

用 rsync -avP source/ target/

别用cp，也别文件管理器里拖放。

一楼说的没错，缓存的问题，KERNEL的写入缓存太大，以至于你从高速存储写往低速设备时出现拥塞瓶颈

限定一下dirty background bytes到比较小的数值测试下卡顿现象，至于多少数值就要你自己测试了，设4M试试看先

下面是一些相关设置的默认值，
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500

以下是Linus Torvalds对相关问题的解释

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS
Date: Fri, 27 Apr 2007 15:19:40 UTC
Message-ID: <fa.+jJfsPdWk8uCcJT/[email protected]>

On Fri, 27 Apr 2007, Mike Galbraith wrote:
>
> As subject states, my GUI is going away for extended periods of time
> when my very full and likely highly fragmented (how to find out)
> filesystem is under heavy write load. While write is under way, if
> amarok (mp3 player) is running, no song change will occur until write is
> finished, and the GUI can go _entirely_ comatose for very long periods.
> Usually, it will come back to life after write is finished, but
> occasionally, a complete GUI restart is necessary.

One thing to try out (and dammit, I should make it the default now in
2.6.21) is to just make the dirty limits much lower. We've been talking
about this for ages, I think this might be the right time to do it.

Especially with lots of memory, allowing 40% of that memory to be dirty is
just insane (even if we limit it to "just" 40% of the normal memory zone.
That can be gigabytes. And no amount of IO scheduling will make it
pleasant to try to handle the situation where that much memory is dirty.

So I do believe that we could probably do something about the IO
scheduling _too_:

- break up large write requests (yeah, it will make for worse IO
througput, but if make it configurable, and especially with
controllers that don't have insane overheads per command, the
difference between 128kB requests and 16MB requests is probably not
really even noticeable - SCSI things with large per-command overheads
are just stupid)

Generating huge requests will automatically mean that they are
"unbreakable" from an IO scheduler perspective, so it's bad for latency
for other reqeusts once they've started.

- maybe be more aggressive about prioritizing reads over writes.

but in the meantime, what happens if you apply this patch?

Actually, you don't need to apply the patch - just do

echo 5 > /proc/sys/vm/dirty_background_ratio
echo 10 > /proc/sys/vm/dirty_ratio

and say if it seems to improve things. I think those are much saner
defaults especially for a desktop system (and probably for most servers
too, for that matter).

Even 10% of memory dirty can be a whole lot of RAM, but it should
hopefully be _better_ than the insane default we have now.

Historical note: allowing about half of memory to contain dirty pages made
more sense back in the days when people had 16-64MB of memory, and a
single untar of even fairly small projects would otherwise hit the disk.
But memory sizes have grown *much* more quickly than disk speeds (and
latency requirements have gone down, not up), so a default that may
actually have been perfectly fine at some point seems crazy these days..

Linus

---
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index f469e3c..a794945 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -67,12 +67,12 @@ static inline long sync_writeback_pages(void)
/*
* Start background writeback (via pdflush) at this percentage
*/
-int dirty_background_ratio = 10;
+int dirty_background_ratio = 5;

/*
* The generator of dirty data starts writeback at this percentage
*/
-int vm_dirty_ratio = 40;
+int vm_dirty_ratio = 10;

/*
* The interval between `kupdate'-style writebacks, in jiffies

@bellchu
@carmark
晚上试试，先谢过

试试rsync

不错

@bellchu
改参数后复制成功，多谢指点