# Intense hard disk activity freeze the system

## ivan2k

Hello,

I recently noticed that my system doesn't respond well to high disk usage.

I have a 5+ yo asus laptop with intel T2400 processor and 2GB DDR2-667 RAM. Hard disk is a seagate 80GB 7200rpm IDE.

If I open a big zip file with ark (KDE), system start to become unresponsiveness, no mouse/keyboard interaction (or very very slow) change virtual desktop become impossible, also scroll down a web page with chromium has no effect.

All of this with a high disk activity and HDD LED always on.

Burning a DVD from ISO image with K3B has the same effect, and a simple command like this:

```
dd if=/dev/zero of=/tmp/bigfile count=1 bs=1600M
```

Cause my system to freeze like above until ending of command.

I was thinking it was a high swapping problem between memory and swap area, so I have search for a solution and tried the change the following parameters:

```
sysctl -w vm.swappiness=1

sysctl -w vm.vfs_cache_pressure=50
```

But these gave me a very small benefits. Even changing I/O scheduler from de default CFQ to deadline or noop won't change.

Thinking of a kernel setting mismatch in memory management, I also tried the 32-bit kernel embedded in System Rescue CD (copying kernel and modules, NOT recompiling using the sysresccd config). But even if seems to response better, still become useless. 

So, what's going on?

Anyone can help me? Suggestions?

Thanks

Ivan

----------

## dE_logics

bs of 1.6 GB will fill up 4 GB of ram, no wonder your system is not responsive.

When your system feels like slowing down, check your swap usage.

Also, what's your i/o scheduler?

----------

## i92guboj

So, did you check if you are hitting swap at all? If you are, then the answer is clear: you are doing things that need more RAM than you own, so, you either do things in a different way, or upgrade your RAM.

The swapiness is only a factor that tells the linux kernel how much you like (or dislike) using swap, but when needed the kernel acts at its own discretion, and does whatever it thinks it's better. If there's no available ram, the kernel has only two options: swap or start oomkill'ing your programs. Your swapiness doesn't increase the amount of physical ram, so it can't really help if you manage to fill it all up.

You are also assuming that the k3b problem is the same problem you are hitting elsewhere. I can't deny it for sure, but there's a chance that they are unrelated. Most of the burners I've found (couple with a crappy disk controller) bring the system to its knees when doing certain operations. Closing optical disks when burning them is one of these operations. There's not much you can do to correct that, other than looking for better hardware when upgrading your mother board and your optical drive(s).

----------

## ivan2k

 *dE_logics wrote:*   

> bs of 1.6 GB will fill up 4 GB of ram, no wonder your system is not responsive.
> 
> When your system feels like slowing down, check your swap usage.
> 
> Also, what's your i/o scheduler?

 

Hi dE_logics,

I know a 'dd' command like that is an extreme test for my system, read about it here:

http://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

I thought linux would slow down but not completely freezing. Was I wrong?

By the way other simple tasks like open a big zip file or burning an ISO of DVD would also suffers (a little better than dd).

I can't check my swap usage because the system is freezing until end, not only slowing down. In the best case I can only move the mouse ...

My I/O scheduler is CFQ, but also tried deadline and noop without differences.

----------

## ivan2k

 *i92guboj wrote:*   

> So, did you check if you are hitting swap at all? If you are, then the answer is clear: you are doing things that need more RAM than you own, so, you either do things in a different way, or upgrade your RAM.
> 
> The swapiness is only a factor that tells the linux kernel how much you like (or dislike) using swap, but when needed the kernel acts at its own discretion, and does whatever it thinks it's better. If there's no available ram, the kernel has only two options: swap or start oomkill'ing your programs. Your swapiness doesn't increase the amount of physical ram, so it can't really help if you manage to fill it all up.
> 
> You are also assuming that the k3b problem is the same problem you are hitting elsewhere. I can't deny it for sure, but there's a chance that they are unrelated. Most of the burners I've found (couple with a crappy disk controller) bring the system to its knees when doing certain operations. Closing optical disks when burning them is one of these operations. There's not much you can do to correct that, other than looking for better hardware when upgrading your mother board and your optical drive(s).

 

Thank you i92guboj, I'm probably too willing with the 'dd' command and my 5+ yo pc (laptop).

'll let lose the dd command and concentrate to ark and k3b tests and let both of you known.

Meanwhile, where can I find a benevolent expert who could send me his kernel configuration (x86)?   :Very Happy: 

Thank you

----------

## avx

Same problem here, kernel 3.1.1 (didn't have time to update, yet). Extracting a big .rar (or some other disk heavy i/o) slows the system to a crawl. Switching virtual desktops takes 30s or more, mouse movement is possible, but neither clicks nor keyboard input is (visibly) accepted.

Core i7 CPU, 12GB DDR3, system hdd is a Samsung 500gb 7.2krpm. Diskencryption (LUKS) is involved, but the CPU is more than potent to handle decryption before hdd-buffers are empty.

Does happen under e17, fvwm and sawfish, everything else is ~amd64.

----------

## dE_logics

 *avx wrote:*   

> Same problem here, kernel 3.1.1 (didn't have time to update, yet). Extracting a big .rar (or some other disk heavy i/o) slows the system to a crawl. Switching virtual desktops takes 30s or more, mouse movement is possible, but neither clicks nor keyboard input is (visibly) accepted.
> 
> Core i7 CPU, 12GB DDR3, system hdd is a Samsung 500gb 7.2krpm. Diskencryption (LUKS) is involved, but the CPU is more than potent to handle decryption before hdd-buffers are empty.
> 
> Does happen under e17, fvwm and sawfish, everything else is ~amd64.

 

This's surely a regression.

----------

## IvanZD

 *ivan2k wrote:*   

> 
> 
> So, what's going on?
> 
> Anyone can help me? Suggestions?
> ...

 

Hello,

what do you have in kernel under 

Processor type and features

for "Preemption Model" ? If it is "no forced preemption" try changing that and recompilig kernel. I doubt it will help much but you can try.

----------

## ivan2k

 *IvanZD wrote:*   

> 
> 
> Hello,
> 
> what do you have in kernel under 
> ...

 

Hi IvanZD,

It's on "Preemptible kernel (low-latency desktop)", I know this is the best choice for desktop users.

I can post my entire .config here but I think will be ugly, is there a better method?

----------

## IvanZD

 *ivan2k wrote:*   

> I can post my entire .config here but I think will be ugly, is there a better method?

 

You can post it here:

http://pastebin.com/

but I doubt it is kernel issue. You tried live CD and it is same, so I don't think you can fix this by changing kernel options.

----------

## IvanZD

Idea: try to run the system without xdm, and test it in console envinronment to exclude possible issues with graphics, video driver or X server.

----------

## ivan2k

 *IvanZD wrote:*   

> Idea: try to run the system without xdm, and test it in console envinronment to exclude possible issues with graphics, video driver or X server.

 

Ok, I've logged out and switch xdm off. Then I launch on tty1 the same dd command as above (I don't know how to open a 5GB .tar.gz file or burn a DVD on console).

Meanwhile I've tried to login on tty2 and it takes a long time before ask me the password (and disk led was always on). So I can't see big differences while running dd.

Except one: a HUGE difference in performance. On console dd show me a performance of  ~33MB/s; instead using yakuake on the KDE environment the speed would be ~9MB/s. Even with no mouse moving and no user interaction.

----------

## avx

Funny, just wanted to copy a few movies on an usbstick and the system again was far from responsible. Haven't done that in ages, but it's never been a problem so far and the stick can only write max at ~5Mb/s.

----------

## i92guboj

 *avx wrote:*   

> Funny, just wanted to copy a few movies on an usbstick and the system again was far from responsible. Haven't done that in ages, but it's never been a problem so far and the stick can only write max at ~5Mb/s.

 

Just to sort out the fs, can you try if dd'ing directly to the pendrive gives you the same data rate?

Anyway, if for you this always worked well, it's time to start trying older kernel releases and see if you can find one that doesn't have this problem (this is when having lots of ancient kernels in /boot pays out   :Laughing:  ).

----------

## ppurka

It really smells like this topic (only amd64): https://forums.gentoo.org/viewtopic-t-793263.html

Maybe the regression has regressed back to the regression.   :Shocked: 

----------

## avx

 *i92guboj wrote:*   

>  *avx wrote:*   Funny, just wanted to copy a few movies on an usbstick and the system again was far from responsible. Haven't done that in ages, but it's never been a problem so far and the stick can only write max at ~5Mb/s. 
> 
> Just to sort out the fs, can you try if dd'ing directly to the pendrive gives you the same data rate?
> 
> Anyway, if for you this always worked well, it's time to start trying older kernel releases and see if you can find one that doesn't have this problem (this is when having lots of ancient kernels in /boot pays out   ).

 dd to (in this case) /dev/sdd directly gives a minimal higher rate, ~5-10%+.

I'll make a note to finally make a kernel update when I get out of bed tomorrow, sources for 3.3.5 have just shown up in portage, so I'll try these. IIRC, I've still got a 2.6.28 lying around somewhere, if that's the case, I'll try that, too.

@ppurka, thanks, I'll read over that tomorrow, too.

FYI, I'm running CFQ scheduler with defaults so far, don't have others built in, but maybe try with the newer kernel.

Edit, just copied over another big file to the stick, this time it's smooth   :Evil or Very Mad: 

----------

## i92guboj

 *avx wrote:*   

>  *i92guboj wrote:*    *avx wrote:*   Funny, just wanted to copy a few movies on an usbstick and the system again was far from responsible. Haven't done that in ages, but it's never been a problem so far and the stick can only write max at ~5Mb/s. 
> 
> Just to sort out the fs, can you try if dd'ing directly to the pendrive gives you the same data rate?
> 
> Anyway, if for you this always worked well, it's time to start trying older kernel releases and see if you can find one that doesn't have this problem (this is when having lots of ancient kernels in /boot pays out   ). dd to (in this case) /dev/sdd directly gives a minimal higher rate, ~5-10%+.
> ...

 

Sorry if it's too obvious, but, did you use the same usb port all the times?

----------

## avx

Yes and no, used both one of the ports directly on the mobo and one of the front, ie copied the same file twice for testing, but it didn't make a difference.

Running on 3.3.5 now, let's see, when it comes back...

----------

