# weird hard drive issues [not solved but no longer a problem]

## Eskarel

I'm not entirely sure if this is the right place for this, or even for that matter the right forum.

I'm getting really poor performance from my primary hard drive(Seagate ST380013A) through hdparm.

```

/dev/hda

Timing cached reads:   1132 MB in  2.01 seconds = 564.39 MB/sec

Timing buffered disk reads:   42 MB in  3.09 seconds =  13.57 MB/sec

The buffer reads vary between about 4 and 14 MB/sec regardless of what settings I use.

This isn't the interesting bit though, the interesting bit is when I run it on the individual partitions on /dev/hda.

/dev/hda1(boot partition grub ext2):

 Timing cached reads:   1112 MB in  2.01 seconds = 554.14 MB/sec

 Timing buffered disk reads:   58 MB in  3.14 seconds =  18.44 MB/sec

/dev/hda2(Windows main partition NTFS):

 Timing cached reads:   1140 MB in  2.00 seconds = 569.52 MB/sec

 Timing buffered disk reads:   36 MB in  3.14 seconds =  11.47 MB/sec

/dev/hda3 is the logical so has no data.

/dev/hda4(/ ext3):

 Timing cached reads:   1128 MB in  2.01 seconds = 562.40 MB/sec

 Timing buffered disk reads:  114 MB in  3.04 seconds =  37.54 MB/sec

/dev/hda5(swap):

 Timing cached reads:   1000 MB in  2.02 seconds = 494.15 MB/sec

 Timing buffered disk reads:  124 MB in  3.05 seconds =  40.61 MB/sec

```

Now do I have a problem in the beginning of my disk(partitions are in disk order, I also suppose earlier partitions would have smaller sectors), has something odd happened to my windows partition which could cause this, or does hdparm just not deal well with ntfs partitions.

I have noticed windows moving very slowly, but I figured it was just that linux was incontravertably superior. I have no problems with the ntfs partition on my other drive hdparm comes in just fine for that.

I apologize that this is psuedo windows stuff, but it's hardware and plus it shows linux to be massively superior and is sort of interesting so I figured it'd be ok.Last edited by Eskarel on Thu Jan 13, 2005 11:09 am; edited 1 time in total

----------

## moocha

Could you please post the output of 

```
hdparm -I /dev/hda
```

? (that's the capital letter i)

----------

## Eskarel

/dev/hda:

ATA device, with non-removable media

	Model Number:       ST380013A                               

	Serial Number:      5JV5VH4H            

	Firmware Revision:  3.06    

Standards:

	Used: ATA/ATAPI-6 T13 1410D revision 2 

	Supported: 6 5 4 3 

Configuration:

	Logical		max	current

	cylinders	16383	64761

	heads		16	1

	sectors/track	63	255

	--

	CHS current addressable sectors:   16514055

	LBA    user addressable sectors:  156301488

	LBA48  user addressable sectors:  156301488

	device size with M = 1024*1024:       76319 MBytes

	device size with M = 1000*1000:       80026 MBytes (80 GB)

Capabilities:

	LBA, IORDY(can be disabled)

	bytes avail on r/w long: 4	Queue depth: 1

	Standby timer values: spec'd by Standard

	R/W multiple sector transfer: Max = 16	Current = 16

	Recommended acoustic management value: 128, current value: 0

	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 

	     Cycle time: min=120ns recommended=120ns

	PIO: pio0 pio1 pio2 pio3 pio4 

	     Cycle time: no flow control=240ns  IORDY flow control=120ns

Commands/features:

	Enabled	Supported:

	   *	READ BUFFER cmd

	   *	WRITE BUFFER cmd

	   *	Host Protected Area feature set

	   *	Look-ahead

	   *	Write cache

	   *	Power Management feature set

		Security Mode feature set

		SMART feature set

	   *	FLUSH CACHE EXT command

	   *	Mandatory FLUSH CACHE command 

	   *	Device Configuration Overlay feature set 

	   *	48-bit Address feature set 

		SET MAX security extension

	   *	DOWNLOAD MICROCODE cmd

	   *	SMART self-test 

	   *	SMART error logging 

Security: 

		supported

	not	enabled

	not	locked

		frozen

	not	expired: security count

	not	supported: enhanced erase

HW reset results:

	CBLID- above Vih

	Device num = 0 determined by CSEL

Checksum: correct

----------

## moocha

Nothing suspicious there and I couldn't find any (consistent) similar reports around the net... Could you re-check timings, but this time using /dev/hda as the benchmark source, as opposed to the individual partitions? I.e. 

```
hdparm -tT /dev/hda
```

 Repeat several times and average out the values. Be aware that those figures mean pretty little if some other processes read from the disk, especially I/O intensive things like emerging stuff. The best way to run such a test is rebooting in single user mode, i.e. adding the 

```
single
```

 command line parameter to the kernel command line in grub (exiting the root shell you will get will let the normal boot process commence). Don't forget to tune the IDE interface if it isn't tuned already since the hdparm init script may not have run yet in single mode.

----------

## Eskarel

Well it seems to have fixed itself. hard drive access to my windows partition was mind bogglingly slow both in windows and in linux, but now it isn't. I didn't really do anything to it that I can think of, but now it seems to be fine.

----------

## bet1m

do you enable dma on kernel?

----------

## Eskarel

I did nothing, nothing at all, and the same problem existed on the same partition in both windows and linux until it all of a sudden stopped existing.

----------

