You are not logged in.
While copying large files from one partition to another partition my system completely stalls. The only thing that keeps working is the music that keeps playing in the background. When I say stall, I mean completely unresponsive, firefox hangs, I can't start the task manager, the clock on the taskbar isn't updated, nothing reacts.
After 4-5 minutes, when the copying is finished, the system becomes usable again. I feel like I tried everything, switching kernel schedulers, using IceWM instead of KDE, using a new harddrive, using 64 bits instead of 32 bits, etc. The motherboard is an Asus P5K, attached is a sata2 harddisk, 7200RPM, 32mb cache. I've seen other people report similar problems maybe someone managed to fix this? I've always had this problem with this system, even when using kernel 2.6.x so maybe it's a hardware limitation/bug?
Offline
this is known bug https://bugzilla.kernel.org/show_bug.cgi?id=12309 and it pisses me off for years...
Offline
Thanks, exactly what I was looking for. I hope it will be fixed eventually.
Offline
Try switching to noop I/O scheduler insetad of CFQ, regardless of what HDD you have.
On the fly:
echo noop > cat /sys/block/sdb/queue/scheduler
Or on boottime, as kernel argument in grub's menu.lst:
elevator=noop
I use it with regular HDD's, and although it may be just a tiny bit slower overall compared to cfq, it doesn't cause your system to start dying on heavy I/O.
Offline
+1 for that karabaja said only if your machine has NCQ/AHCI enabled.
You may also which to try the linux-ck kernel package which minimizes lag effect - at least on my system (links in my sig).
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
The noop scheduler does not make any difference on my system, although I have AHCI enabled. I will try the ck kernel and see how that works out
Offline
tunables to the rescue.
echo 1 > /proc/sys/vm/dirty_ratio
should help.
Offline
It's sounds like this is a bigger issue and was repeated many times on the forum and there is many tweaks available, maybe someone with better english would make wiki entry for that?
Offline
I have the same motherboard and I have the same problem in windows, though I haven't noticed it in arch yet. I'm gonna try copying a couple .iso's over from my ntfs partition and see what happens.
EDIT: 7.4GB ISO copied over from ntfs partition to ext4, no issues. Same ISO copied from ntfs /dev/sdb3 to ntfs /dev/sda2 and also, no issues. Weird. Seems I'm unaffected.
Last edited by biltong (2011-09-12 11:25:16)
Offline
I have the same motherboard and I have the same problem in windows, though I haven't noticed it in arch yet. I'm gonna try copying a couple .iso's over from my ntfs partition and see what happens.
EDIT: 7.4GB ISO copied over from ntfs partition to ext4, no issues. Same ISO copied from ntfs /dev/sdb3 to ntfs /dev/sda2 and also, no issues. Weird. Seems I'm unaffected.
I does not always happen with the same intensity. So, you might just be lucky for now. The problem happens the most frequently when copying files on the same disk, e.g. from /dev/sda2 to /dev/sda3.
Offline
I tried that too and it was fine. Does it happen only with big files or millions of small files too? A friend of mine has an issue on his PC where he can't copy large files and use his PC at the same time otherwise the system goes for a BSOD. Maybe it's something hardware related?
Offline
https://bbs.archlinux.org/viewtopic.php … 7#p1023237
Workaround:
adding
{username} - priority -2
at the end of
/etc/security/limits.conf
helps a lot.
Add users to limit.conf with high priority on Arch x64, a lot responsive now on high disk i/o usage on archlinux x86_64
grep home /etc/passwd|sed 's/:.*$/ - priority -2/g' >> /etc/security/limits.conf
Offline
There is definitely something extremely wrong with CFQ.
On 2 different PCs (both Arch) I had an extreme pain writing on USB sticks (not always same sticks).
Right now I could not even dd a Fedora ISO to a USB key... just using dd or redirecting cat to the block device would freeze my system at some point, before it freezes I can fire iotop and see it is not even writing anything !?
So I moved from CFQ to deadline on all my sdX and now I have achieved my write on USB key...
I'll edit my grub config to set the default I/O scheduler to something else than CFQ because it is really bugged right now. I don't know if it is Arch related or all Linux-wide but it is very very bad...
Offline
Try setting hugepage defrag to madvise
Set to madvise
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag
Disable
echo never > /sys/kernel/mm/transparent_hugepage/defrag
See https://bbs.archlinux.org/viewtopic.php … 8#p1033648
Setting hugepage defrag to madvise has drasticly reduced the problem, if not completely solved it (further testing needed), for me!
Offline