Disk operations freeze Debian
I have just installed Debian testing on my new desktop and I am not very happy with performance - when I perform a disk intensive operation, e.g. upgrade packages in the system, everything seems to freeze, e.g. changing tabs in Iceweasel takes 3 seconds. I run the Debian on my 3 year old Thinkpad X60 ultra-portable, and I don't have these issues. (every single parameter of the laptop is much worse than the desktop).
I am using the default packaged kernel and scripts.
I run
hdparm -t /dev/sda1
And I got around 96GB/s, which is expected. What else can I try to make it work better?
EDIT:
grzes:/home/ga# hdparm -i /dev/sda
/dev/sda:
Model=WDC WD15EARS-00Z5B1, FwRev=80.00A80, SerialNo=WD-WMAVU1362357
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=2930277168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
EDIT2: Even my wife said "on this new computer I can't do anything when I copy the photos from the camera and its much worse than on the old one". So it must be serious.
EDIT3: Updated to 2.6.32, but still no improvement
EDIT4: I forgot to mention that the new disk is ext4, the old was ext3.
EDIT5: Still not solved. I have a P43 ASUS P5QL-E board. Lines from dmesg that seem relevant:
[ 0.370850] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 0.370852] io scheduler noop registered
[ 0.370853] io scheduler anticipatory registered
[ 0.370854] io scheduler deadline registered
[ 0.370876] io scheduler cfq registered (default)
...
[ 0.908233] ata_piix 0000:00:1f.2: version 2.13
[ 0.908243] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.908246] ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
[ 0.908275] ata_piix 0000:00:1f.2: setting latency timer to 64
[ 0.908316] scsi0 : ata_piix
[ 0.908374] scsi1 : ata_piix
[ 0.909180] ata1: SATA max UDMA/133 cmd 0xa000 ctl 0x9c00 bmdma 0x9480 irq 19
[ 0.909183] ata2: SATA max UDMA/133 cmd 0x9880 ctl 0x9800 bmdma 0x9488 irq 19
[ 0.909199] ata_piix 0000:00:1f.5: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 0.909202] ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ]
[ 0.909228] ata_piix 0000:00:1f.5: setting latency timer to 64
[ 0.909279] scsi2 : ata_piix
[ 0.909326] scsi3 : ata_piix
[ 0.910021] ata3: SATA max UDMA/133 cmd 0xb000 ctl 0xac00 bmdma 0xa480 irq 19
Check the offset for the partition - needs to be divisable by 4 for EARS as they have the 4096 technology. If it isn't - repartition it to get alignment and performance issues should go away (misaligned EARS drives will be doing a lot more sector writes per op).
I had similar freeze issue when doing a lot of disk IOs. During a backup the desktop was freezing for a few seconds again and again until the backup finished.
It was not related to any alignment nor any hdparm tuning (although I agree it will help).
The system lockup was caused by the IO scheduler which delays too much some IOs required by more interactive applications (Firefox, KDE or whatever). The faulty IO scheduler was cfg.
To solve the issue, you have to use the deadline IO scheduler. You activate it on a disk with the following command that you can add in /etc/rc.local:
echo deadline > /sys/block/sda/queue/scheduler
Check Solving Linux system lock up when intensive disk I/O are performed for more information.
It's a shot in the dark, but I've had a problem like this a while ago, and the cause turned out to be that the kernel did not support the chipset completely and DMA was turned off. Check with
hdparm -i /dev/sda
whether one of the DMA modes is enabled.
(The solution in that case was to get a newer kernel.)