Slow partition: how to check?
Hello all, hdparm tells me that one of my partitions is really slow. While hda3 for instance gives me about 40-50 MB/s, hda4 only gives 4-8 MB/s. hda4 is part of a RAID partition together with hdc4. While hdc4 also gives about 40-50 MB/s, hda4 appears to be very slow. Does anyone know what might cause this, and how I might check or correct what is wrong? Regards, Pieter Hulshoff
The Saturday 2005-01-22 at 21:06 +0100, Pieter Hulshoff wrote:
hdparm tells me that one of my partitions is really slow. While hda3 for instance gives me about 40-50 MB/s, hda4 only gives 4-8 MB/s. hda4 is part of a RAID partition together with hdc4. While hdc4 also gives about 40-50 MB/s, hda4 appears to be very slow. Does anyone know what might cause this, and how I might check or correct what is wrong?
Try with the raid umounted. Just a wild guess. -- Cheers, Carlos Robinson
On Sunday 23 January 2005 03:28, Carlos E. R. wrote:
The Saturday 2005-01-22 at 21:06 +0100, Pieter Hulshoff wrote:
hdparm tells me that one of my partitions is really slow. While hda3 for instance gives me about 40-50 MB/s, hda4 only gives 4-8 MB/s. hda4 is part of a RAID partition together with hdc4. While hdc4 also gives about 40-50 MB/s, hda4 appears to be very slow. Does anyone know what might cause this, and how I might check or correct what is wrong?
Try with the raid umounted. Just a wild guess.
The results were the same I'm afraid. Regards, Pieter Hulshoff
The Sunday 2005-01-23 at 09:20 +0100, Pieter Hulshoff wrote:
Try with the raid umounted. Just a wild guess.
The results were the same I'm afraid.
I don't know then... check the media for badblocks, just in case. Both drives are similar? This wekend my HD was very slow, and gkrellm didn't show activity. Then I noticed that smartd had launched it online test. But this only lasts around an hour. -- Cheers, Carlos Robinson
On Tuesday 25 January 2005 8:38 pm, Carlos E. R. wrote:
The Sunday 2005-01-23 at 09:20 +0100, Pieter Hulshoff wrote:
Try with the raid umounted. Just a wild guess.
The results were the same I'm afraid.
I don't know then... check the media for badblocks, just in case. Both drives are similar?
This wekend my HD was very slow, and gkrellm didn't show activity. Then I noticed that smartd had launched it online test. But this only lasts around an hour.
-- Cheers, Carlos Robinson
Could be the partition table or the partition itself is corrupt. It may affect one or all partitions on a disk. Diagnosis is usually by repartitioning and reformatting either the suspect partition or more often the whole drive. I haven't found any useful diagnosis tool to detect this condition other than repartitioning and reformatting and the 'problem' isn't there any more. Stan
Could be the partition table or the partition itself is corrupt. It may affect one or all partitions on a disk. Diagnosis is usually by repartitioning and reformatting either the suspect partition or more often the whole drive. I haven't found any useful diagnosis tool to detect this condition other than repartitioning and reformatting and the 'problem' isn't there any more. 1 (dangerous) possibility is to record the information from the existing
On Thursday 27 January 2005 14:07, Stan Glasoe wrote:
partition table (Starting and ending cylinders, partition type, et. al.).
Then using a partition tool rebuild it. This should not affect the
formatting of any of the partitions, and should clean up any corruption in
the partition tables themselves.
The reformatting of the offending partition should clean up that partition,
but will delete all the data in that partition.
Another thing that can cause slowness is bad blocks. Normally when a drive
is formatted at the factory, the bad blocks are hidden from software. But,
if there are some exposed bad blocks in your partition, your system could
be slowed down by retries, etc.
--
Jerry Feldman
The Thursday 2005-01-27 at 14:30 -0500, Jerry Feldman wrote:
Another thing that can cause slowness is bad blocks. Normally when a drive is formatted at the factory, the bad blocks are hidden from software. But, if there are some exposed bad blocks in your partition, your system could be slowed down by retries, etc.
That's what I was thinking of. Simply writing to the bad sector will cause the HD firmware to remap it out of view. -- Cheers, Carlos Robinson
On Thursday 27 January 2005 20:30, Jerry Feldman wrote:
On Thursday 27 January 2005 14:07, Stan Glasoe wrote: The reformatting of the offending partition should clean up that partition, but will delete all the data in that partition.
Hmm, I'll have to see where I leave all the data on that partition. I'm seriously running out of diskspace here.
Another thing that can cause slowness is bad blocks. Normally when a drive is formatted at the factory, the bad blocks are hidden from software. But, if there are some exposed bad blocks in your partition, your system could be slowed down by retries, etc.
Any way I can check the entire partition for bad blocks? Regards, Pieter
On Saturday 29 January 2005 01:25, Carlos E. R. wrote:
The Friday 2005-01-28 at 07:02 +0100, Pieter Hulshoff wrote:
Any way I can check the entire partition for bad blocks?
man badblocks
Ok, that was _way_ too obvious for me... don't I feel foolish. Anywho, I ran badblocks, but it found no bad blocks whatsoever. On one hand I feel happy about this, but that still leaves me with no explanation to the slowness of my partition. :( Anyone got any ideas/suggestions? Regards, Pieter Hulshoff
Pieter Hulshoff wrote:
Anyone got any ideas/suggestions?
I didn't see you reply to my answer Mon, 24 Jan 2005 18:54:11 -0500 to your first thread "Please help: one partition MUCH slower than the others". Is there any point trying again? I don't recall seeing you tell anyone the brand or model of HD or the logical position or size of the slow partition on the HD, or its position on the cable, or the cable type. -- "The message of the cross is foolishness to those who are perishing, but to us who are being saved, it is the power of God." 1 Corinthians 1:18 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/
On Saturday 29 January 2005 18:45, Felix Miata wrote:
Pieter Hulshoff wrote:
Anyone got any ideas/suggestions?
I didn't see you reply to my answer Mon, 24 Jan 2005 18:54:11 -0500 to your first thread "Please help: one partition MUCH slower than the others". Is there any point trying again? I don't recall seeing you tell anyone the brand or model of HD or the logical position or size of the slow partition on the HD, or its position on the cable, or the cable type.
My apologies for that. The only reply I remember you giving was a true statement in itself ("End of disk partitions can be considerably slower than those at the front, but factor of 10 is more than I can recall ever seeing."), but I didn't think you were looking for a reply. My apologies misunderstanding. The disk in question is a Maxtor 6Y160P0, just like most of my other disks. It's being run off the first IDE interface of my on-board RAID controller (hda) (which I don't use for RAID). On the slave of that IDE interface (hdb), and on master and slave of the 2nd IDE interface (hdc/hdd) are 3 more disks of the same type. On the first IDE of my normal IDE controller (hde) is a 60 GB windows '98 disk, and hdf/hdh are my cd burner and my DVD player. I'm using round IDE cables for all my discs, and since most of the discs are located very close to the connectors I'm using short cables for all except hde/hdf. The slow partition (hda4) is at the end of the disk, running from cylinder 2119 to 19929. hdc is set up exactly like hda, but does not suffer from any slowdown on any of its partitions. I've tested them even from a rescue disk, with none of the partitions mounted, but the results were the same: hda4 is about 5-12 times slower than the other partitions. Regards, Pieter Hulshoff
The Saturday 2005-01-29 at 20:08 +0100, Pieter Hulshoff wrote:
GB windows '98 disk, and hdf/hdh are my cd burner and my DVD player. I'm using round IDE cables for all my discs, and since most of the discs are located very close to the connectors I'm using short cables for all except hde/hdf.
I understand that round cables perform somewhat worse than flat cables. I know they are nice, easier to handle, etc. But the flat ribbon cable has a ground wire parallel and at both sides to each signal wire, thus shielding each signal wire from the rest. This can not be done on a round cable, or not su much. However, I don't see how that would affect one partition, and not the rest. You have got a strange case... Still, if you have a flat cable around (high speed type, 80 wires), try it. If it works, very good; if it doesn't, then you know it wasn't that :-) -- Cheers, Carlos Robinson
On Sunday 30 January 2005 02:07, Carlos E. R. wrote:
Still, if you have a flat cable around (high speed type, 80 wires), try it. If it works, very good; if it doesn't, then you know it wasn't that :-)
I'll have a look around. I think I may have a few of these left in my junk box. :) Regards, Pieter Hulshoff
On Sat, 29 Jan 2005 20:08:56 +0100, Pieter Hulshoff
On Saturday 29 January 2005 18:45, Felix Miata wrote:
Pieter Hulshoff wrote:
Anyone got any ideas/suggestions?
I didn't see you reply to my answer Mon, 24 Jan 2005 18:54:11 -0500 to your first thread "Please help: one partition MUCH slower than the others". Is there any point trying again? I don't recall seeing you tell anyone the brand or model of HD or the logical position or size of the slow partition on the HD, or its position on the cable, or the cable type.
My apologies for that. The only reply I remember you giving was a true statement in itself ("End of disk partitions can be considerably slower than those at the front, but factor of 10 is more than I can recall ever seeing."), but I didn't think you were looking for a reply. My apologies misunderstanding.
The disk in question is a Maxtor 6Y160P0, just like most of my other disks. It's being run off the first IDE interface of my on-board RAID controller (hda) (which I don't use for RAID). On the slave of that IDE interface (hdb), and on master and slave of the 2nd IDE interface (hdc/hdd) are 3 more disks of the same type. On the first IDE of my normal IDE controller (hde) is a 60 GB windows '98 disk, and hdf/hdh are my cd burner and my DVD player. I'm using round IDE cables for all my discs, and since most of the discs are located very close to the connectors I'm using short cables for all except hde/hdf.
The slow partition (hda4) is at the end of the disk, running from cylinder 2119 to 19929. hdc is set up exactly like hda, but does not suffer from any slowdown on any of its partitions. I've tested them even from a rescue disk, with none of the partitions mounted, but the results were the same: hda4 is about 5-12 times slower than the other partitions.
Regards,
Pieter Hulshoff
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Hi, I do not know your exact problem, but my experience with this specific disk are really bad. I had 3 of them replaced. And with all of them the problem was with bad blocks (a lot) in the second part of the disk. The latest one is stable, but the older ones was real s..., They was formated OK. I had run on all of them the diags, etc. But after some time they became slow (the partitions which were after the half of the disk). So, you should create a diag diskette from the CD, came with the disk. After the errors it reported, Maxtor were more than convinced to replace the drives. 2 times :). The last one works OK, even there is some strange noise when it moves the head when it deals with partitions at the end of the disk. It runs OK already 6 months. But just to be sure I had added a new one as RAID1 to mirror it. Sunny -- Get Firefox http://www.spreadfirefox.com/?q=affiliates&id=10745&t=85
On Sunday 30 January 2005 10:26, Sunny wrote:
I do not know your exact problem, but my experience with this specific disk are really bad.
Interesting; I've had no (others) problems whatsoever, and I've used these kind of disks in several of my computers. I've already checked them for bad blocks, but found none so far. I'm starting to consider somehow making a backup of my data, and just repartition the disk to see if it helps. Now, where do I backup about 250 MB of data?... :) Regards, Pieter Hulshoff
Pieter, On Sunday 30 January 2005 03:05, Pieter Hulshoff wrote:
On Sunday 30 January 2005 10:26, Sunny wrote:
I do not know your exact problem, but my experience with this specific disk are really bad.
Interesting; I've had no (others) problems whatsoever, and I've used these kind of disks in several of my computers. I've already checked them for bad blocks, but found none so far. I'm starting to consider somehow making a backup of my data, and just repartition the disk to see if it helps. Now, where do I backup about 250 MB of data?... :)
I believe the user-level "badblocks" utility is pretty limited in what it can detect and report. The only bad blocks it can detect are those that, upon access, cause an overt, unrecoverable hardware I/O error reported back to the user level software. Modern disk drives have internal bad-block remapping. As manufactured, there is a reserve of sectors available to use when the computer requests a block known to be bad (based on an record of bad blocks maintained by the drive itself). The initial bad-block remapping is done during manufacture (after burn-in, I think). Each manufacturer has to set a standard for the number or percentage of blocks that can be bad and the disk still shipped. (Very few high-capacity drives are literally defect-free.) The list of mapped blocks can be added to during ordinary use when an in-use block becomes unable to accurately record data. The larger the number of such drive-mapped bad blocks (in a given region of the disk), the worse the performance (for that region). I'm under the impression that access to these bad-block remapping tables is not part of the SCSI or IDE standard and hence depends on manufacturer- and /or drive-specific software and device-level commands.
Regards,
Pieter Hulshoff
Please note the uncertain wording throughout this message. It's been several years since I did OS- and device-level programming, and some of this information may be out of date or I may be remembering it poorly. However, the upshot is there is transparent bad-block remapping in modern hard drives and the more it's used in a given unit the more performance degrades. Randall Schulz
On Sunday 30 January 2005 16:53, Randall R Schulz wrote:
Modern disk drives have internal bad-block remapping. As manufactured, there is a reserve of sectors available to use when the computer requests a block known to be bad (based on an record of bad blocks maintained by the drive itself). The initial bad-block remapping is done during manufacture (after burn-in, I think). Each manufacturer has to set a standard for the number or percentage of blocks that can be bad and the disk still shipped. (Very few high-capacity drives are literally defect-free.) The list of mapped blocks can be added to during ordinary use when an in-use block becomes unable to accurately record data.
Is there any way one can check for such bad blocks since as you say the badblocks program won't catch them? As I wrote: smartctl didn't report any problems either. The way you describe it, such errors might/should be a part of smart? Regards, Pieter Hulshoff
On Sunday 30 Jan 2005 16:01 pm, Pieter Hulshoff wrote:
On Sunday 30 January 2005 16:53, Randall R Schulz wrote:
Modern disk drives have internal bad-block remapping. As manufactured, there is a reserve of sectors available to use when the computer requests a block known to be bad (based on an record of bad blocks maintained by the drive itself). The initial bad-block remapping is done during manufacture (after burn-in, I think). Each manufacturer has to set a standard for the number or percentage of blocks that can be bad and the disk still shipped. (Very few high-capacity drives are literally defect-free.) The list of mapped blocks can be added to during ordinary use when an in-use block becomes unable to accurately record data.
Is there any way one can check for such bad blocks since as you say the badblocks program won't catch them? As I wrote: smartctl didn't report any problems either. The way you describe it, such errors might/should be a part of smart?
Check the support downloads on the manufacturer's web site for a diagnostics tool. Dylan
Regards,
Pieter Hulshoff
-- "I see your Schwartz is as big as mine" -Dark Helmet
On Sunday 30 January 2005 17:12, Dylan wrote:
On Sunday 30 Jan 2005 16:01 pm, Pieter Hulshoff wrote:
Is there any way one can check for such bad blocks since as you say the badblocks program won't catch them? As I wrote: smartctl didn't report any problems either. The way you describe it, such errors might/should be a part of smart?
Check the support downloads on the manufacturer's web site for a diagnostics tool.
I presume this is the same one Sunny spoke of? I'll have a look at it asap. Regards, Pieter Hulshoff
On Sunday 30 January 2005 10:01, Pieter Hulshoff wrote:
On Sunday 30 January 2005 16:53, Randall R Schulz wrote:
Modern disk drives have internal bad-block remapping. As manufactured, there is a reserve of sectors available to use when the computer requests a block known to be bad (based on an record of bad blocks maintained by the drive itself). The initial bad-block remapping is done during manufacture (after burn-in, I think). Each manufacturer has to set a standard for the number or percentage of blocks that can be bad and the disk still shipped. (Very few high-capacity drives are literally defect-free.) The list of mapped blocks can be added to during ordinary use when an in-use block becomes unable to accurately record data.
Is there any way one can check for such bad blocks since as you say the badblocks program won't catch them? As I wrote: smartctl didn't report any problems either. The way you describe it, such errors might/should be a part of smart?
On the CD supplied from Maxtor, which came with my drives, there was an option on one of the menus to create a diskette with diagnostic tools. The same diag tool is included in the ultimate boot cd (http://ultimatebootcd.com). Sunny
Regards,
Pieter Hulshoff
-- Get Firefox http://www.spreadfirefox.com/?q=affiliates&id=10745&t=85
The Sunday 2005-01-30 at 17:01 +0100, Pieter Hulshoff wrote:
Is there any way one can check for such bad blocks since as you say the badblocks program won't catch them? As I wrote: smartctl didn't report any problems either. The way you describe it, such errors might/should be a part of smart?
There is a counter: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 096 096 036 Pre-fail Always - 41 The first one belongs to a drive that I know reallocated some sectors, the second didn't (both are quassi the same model, just different cappacity). The problem is how to interpret it, but I think it counts down. When it reaches 36, disk to the dustbin fast. -- Cheers, Carlos Robinson
On Monday 31 January 2005 03:04, Carlos E. R. wrote:
The Sunday 2005-01-30 at 17:01 +0100, Pieter Hulshoff wrote: There is a counter:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0033 096 096 036 Pre-fail Always - 41
The first one belongs to a drive that I know reallocated some sectors, the second didn't (both are quassi the same model, just different cappacity). The problem is how to interpret it, but I think it counts down. When it reaches 36, disk to the dustbin fast.
Here's the data from my drives: /dev/hda, /dev/hdb, /dev/hdd: 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0 /dev/hdc: 5 Reallocated_Sector_Ct 0x0033 242 242 063 Pre-fail Always - 117 If your interpretation is correct, then hda, hdb, and hdd (1st one is the problem disk, last two disks are one month old!) should all be sent to the dustbin? Regards, Pieter Hulshoff
The Monday 2005-01-31 at 06:49 +0100, Pieter Hulshoff wrote:
There is a counter:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0033 096 096 036 Pre-fail Always - 41
The first one belongs to a drive that I know reallocated some sectors, the second didn't (both are quassi the same model, just different cappacity). The problem is how to interpret it, but I think it counts down. When it reaches 36, disk to the dustbin fast.
Here's the data from my drives: /dev/hda, /dev/hdb, /dev/hdd: 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0 /dev/hdc: 5 Reallocated_Sector_Ct 0x0033 242 242 063 Pre-fail Always - 117
If your interpretation is correct, then hda, hdb, and hdd (1st one is the problem disk, last two disks are one month old!) should all be sent to the dustbin?
On the contrary. The threshold value is 063 for your disk. The present value is 242, which is way higher, so you have still a lot of room. I think your hdc has some reallocated sectors, and hda none. But as I say, I have difficulties interpreting those readouts. You can verify with the option --health if unsure: nimrodel:~ # smartctl --health /dev/hda smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED -- Cheers, Carlos Robinson
On Tuesday 01 February 2005 03:46, Carlos E. R. wrote:
On the contrary. The threshold value is 063 for your disk. The present value is 242, which is way higher, so you have still a lot of room.
I think your hdc has some reallocated sectors, and hda none. But as I say, I have difficulties interpreting those readouts. You can verify with the option --health if unsure:
Yep, they all pass the --health test. :) Ok, guess I really need to fire up that Maxtor disk utility, and otherwise just repartition, and reformat. Regards, Pieter Hulshoff
Well, it took me a while, but I finally managed to figure out what the problem was: low power. It appears my power supply was just a tad too weak to power up all the devices, and it left me with a slow partition, and the chance of lock-up during heavy CPU activity. I've currently disconnected 2 drives, and the whole system's as stable as it should be. Guess I'd better buy me a better PSU... Thanx for all the help with this one though; I learned a lot. :) Regards, Pieter Hulshoff
The Thursday 2005-04-07 at 23:13 +0200, Pieter Hulshoff wrote:
Well, it took me a while, but I finally managed to figure out what the problem was: low power.
:-o
It appears my power supply was just a tad too weak to power up all the devices, and it left me with a slow partition, and the chance of lock-up during heavy CPU activity. I've currently disconnected 2 drives, and the whole system's as stable as it should be. Guess I'd better buy me a better PSU... Thanx for all the help with this one though; I learned a lot. :)
Good to know, after all this time... :-) -- Cheers, Carlos Robinson
The disk in question is a Maxtor 6Y160P0, just like most of my other disks. It's being run off the first IDE interface of my on-board RAID controller (hda) (which I don't use for RAID). On the slave of that IDE interface (hdb), and on master and slave of the 2nd IDE interface (hdc/hdd) are 3 more disks of the same type. On the first IDE of my normal IDE controller (hde) is a 60 GB windows '98 disk, and hdf/hdh are my cd burner and my DVD player. I'm using round IDE cables for all my discs, and since most of the discs are located very close to the connectors I'm using short cables for all except hde/hdf.
The slow partition (hda4) is at the end of the disk, running from cylinder 2119 to 19929. hdc is set up exactly like hda, but does not suffer from any slowdown on any of its partitions. I've tested them even from a rescue disk, with none of the partitions mounted, but the results were the same: hda4 is about 5-12 times slower than the other partitions. Everyone including me has been looking at hardware. One difference, is that I assume that your swap space is on that disk. If you are swapping, you are going to have head movement that you do not see on /dev/hdc. One suggestion is to either turn off swap altogether, or place it on /dev/hdc for testing purposes. Then run a benchmark test on that
On Saturday 29 January 2005 14:08, Pieter Hulshoff wrote:
partition. The key is to keep the heads near /dev/hda4. Also remember,
that program loading is going to come from your / and /usr file systems.
And also remember that libraries and program text segments are swapped in
from where they reside, so even if you move the swap space, any swapping
will cause head movements on /dev/hda.
A much better test would be to boot a standalone system, such as the SuSE
evaluation or Knoppix (make sure you do not swap to /dev/hda) as Knoppix
will want to grab the swap partition. Effectively, what we need to do is
to eliminate the effect of head movement between the other active
partitions.
--
Jerry Feldman
On Mon, Jan 31, 2005 at 08:48:55AM -0500, Jerry Feldman wrote:
On Saturday 29 January 2005 14:08, Pieter Hulshoff wrote: One difference, is that I assume that your swap space is on that disk. If you are swapping, you are going to have head movement that you do not see on /dev/hdc.
swap space is indeed on that disk (/dev/hda2), but as I indicated in one of the (many:) previous posts: I've done the same tests from a rescue cd, without any of the partitions mounted, and the results were the same. Also: /dev/hda1 and /dev/hda3 are not showing the same slowdown. Regards, Pieter Hulshoff
On Monday 31 January 2005 08:55, Pieter Hulshoff wrote:
swap space is indeed on that disk (/dev/hda2), but as I indicated in one of the (many:) previous posts: I've done the same tests from a rescue cd, without any of the partitions mounted, and the results were the same. Also: /dev/hda1 and /dev/hda3 are not showing the same slowdown. When you ran from the rescue, did you check to see if swap was disabled.
In any case, your drive could be bad eventhough no badblocks are detected.
There could be an excessive number of retries.
--
Jerry Feldman
On Mon, Jan 31, 2005 at 10:04:41AM -0500, Jerry Feldman wrote:
On Monday 31 January 2005 08:55, Pieter Hulshoff wrote:
swap space is indeed on that disk (/dev/hda2), but as I indicated in one of the (many:) previous posts: I've done the same tests from a rescue cd, without any of the partitions mounted, and the results were the same. Also: /dev/hda1 and /dev/hda3 are not showing the same slowdown. When you ran from the rescue, did you check to see if swap was disabled.
Not that I recall. Does SuSE rescue automatically allocate the swap space on the HDs, and use it?
In any case, your drive could be bad eventhough no badblocks are detected. There could be an excessive number of retries.
I intend to run that Maxtor utility on it later this week to see if it can figure out if something's wrong. The tests that can be performed are limited since data is on the disk. I really must consider finding a place to store that data, and perform a complete HD test. Regards, Pieter Hulshoff
On Wednesday 26 January 2005 03:38, Carlos E. R. wrote:
The Sunday 2005-01-23 at 09:20 +0100, Pieter Hulshoff wrote:
Try with the raid umounted. Just a wild guess.
The results were the same I'm afraid.
I don't know then... check the media for badblocks, just in case. Both drives are similar?
This wekend my HD was very slow, and gkrellm didn't show activity. Then I noticed that smartd had launched it online test. But this only lasts around an hour.
I've ran smartctl checks on it, but no problems were shown. I don't have smartd running, so that shouldn't be able to be the cause of the slowness. How can I check for badblocks? I've run a file system check on it already, but it didn't show any problems either. Regards, Pieter Hulshoff
Pieter, On Saturday 22 January 2005 12:06, Pieter Hulshoff wrote:
Hello all,
hdparm tells me that one of my partitions is really slow. While hda3 for instance gives me about 40-50 MB/s, hda4 only gives 4-8 MB/s. hda4 is part of a RAID partition together with hdc4. While hdc4 also gives about 40-50 MB/s, hda4 appears to be very slow. Does anyone know what might cause this, and how I might check or correct what is wrong?
Regards,
Pieter Hulshoff
How about showing us actual output from hdparam. Not only from the speed test options, but from the device information options, too. There may be some clues therein. Something like this: % hdparm -v -i -t /dev/hda /dev/hda: HDIO_GET_MULTCOUNT failed: Invalid argument IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Invalid argument Model=SONY DVD RW DRU-510A, FwRev=1.0d, SerialNo=EA3FE1B6 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=0kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 AdvancedPM=no Drive conforms to: device does not report version: * signifies the current active mode Timing buffered disk reads: 16 MB in 3.19 seconds = 5.01 MB/sec The only IDE devices on my system are DVDs, so there's no meaningful speed comparison with a hard drive. Randall Schulz
On Saturday 29 January 2005 20:25, Randall R Schulz wrote:
How about showing us actual output from hdparam. Not only from the speed test options, but from the device information options, too. There may be some clues therein. hdparm -v -i -t /dev/hda
Ok, I ran this on /dev/hda, /dev/hda3, /dev/hda4, /dev/hdc, /dev/hdc3, and /dev/hdc4, and below's the output. Since I'm doing this from a running system, results will be lower than indicated in previous emails (got a few other programs running as well right now; if needs be I'll run this from a recue disk later to get you unmounted performance; hda and hdc are about equally used (software RAID) so the relative performance should be ok). /dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 320173056, start = 0 Model=Maxtor 6Y160P0, FwRev=YAR41BW0, SerialNo=Y43XR0JE Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: (null): * signifies the current active mode Timing buffered disk reads: 84 MB in 3.08 seconds = 27.29 MB/sec /dev/hda3: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 30009420, start = 4016250 Timing buffered disk reads: 88 MB in 3.03 seconds = 29.02 MB/sec /dev/hda4: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 286133715, start = 34025670 Timing buffered disk reads: 20 MB in 3.12 seconds = 6.41 MB/sec /dev/hdc: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 320173056, start = 0 Model=Maxtor 6Y160P0, FwRev=YAR41BW0, SerialNo=Y43XR33E Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: (null): * signifies the current active mode Timing buffered disk reads: 108 MB in 3.02 seconds = 35.72 MB/sec /dev/hdc3: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 30009420, start = 4016250 Timing buffered disk reads: 88 MB in 3.02 seconds = 29.10 MB/sec /dev/hdc4: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 286117650, start = 34025670 Timing buffered disk reads: 114 MB in 3.05 seconds = 37.38 MB/sec Regards, Pieter Hulshoff
On Saturday 29 January 2005 02:39 pm, Pieter Hulshoff wrote:
On Saturday 29 January 2005 20:25, Randall R Schulz wrote:
How about showing us actual output from hdparam. Not only from the speed test options, but from the device information options, too. There may be some clues therein. hdparm -v -i -t /dev/hda
Ok, I ran this on /dev/hda, /dev/hda3, /dev/hda4, /dev/hdc, /dev/hdc3, and /dev/hdc4, and below's the output. Since I'm doing this from a running system, results will be lower than indicated in previous emails (got a few other programs running as well right now; if needs be I'll run this from a recue disk later to get you unmounted performance; hda and hdc are about equally used (software RAID) so the relative performance should be ok).
/dev/hda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 19929/255/63, sectors = 320173056, start = 0 [...] Regards,
Pieter Hulshoff =========
Pieter, Sorry, I haven't been following this thread closely, but saw something that threw up a red flag. I thought I would at least suggest it to you at this point. I notice that you have IO_support = 1 (32-bit). First question/suggestion is do you have an ATA100/133 cable connected to the drive? That's the one with 80 wires, but still 40 pins. Second, have you tried changing that bit to 0 (16-bit)? I think you might see a difference in your readings. Test with hdparm -T /dev/hdx & hdparm -t /dev/hdx, as that will give you both cache read & drive read speeds. I know you can set the IO_support setting with hdparm -c0 (16-bit) or -c1 (32-bit). Also, in checking my settings, I notice that unmaskirq is 0 (off) as well. Sorry, don't remember the option to change that, just do "hdparm --help" for all your options. hopefully helpful, Lee -- --- KMail v1.7.2 --- SuSE Linux Pro v9.2 --- Registered Linux User #225206 "Don't let the fear of striking out keep you from playing the game!"
On Sunday 30 January 2005 01:10, BandiPat wrote:
Sorry, I haven't been following this thread closely, but saw something that threw up a red flag. I thought I would at least suggest it to you at this point. I notice that you have IO_support = 1 (32-bit).
First question/suggestion is do you have an ATA100/133 cable connected to the drive? That's the one with 80 wires, but still 40 pins. Second, have you tried changing that bit to 0 (16-bit)? I think you might see a difference in your readings. Test with hdparm -T /dev/hdx & hdparm -t /dev/hdx, as that will give you both cache read & drive read speeds. I know you can set the IO_support setting with hdparm -c0 (16-bit) or -c1 (32-bit). Also, in checking my settings, I notice that unmaskirq is 0 (off) as well. Sorry, don't remember the option to change that, just do "hdparm --help" for all your options.
I've played around with those already (tried again just now though, just to make sure), but none of those appear to have much results on the speed. The unmaskirq 1 seems to help a little when there's a lot of internet traffic going on, but otherwise there's little to no effect. Also, all the drives have the same settings, yet it's only this one partition on this one drive that has these speed problems. There's no errors from filesystem check, badsectors, nor from smartctl. Thanx for the suggestions though, they could have held the answer. Regards, Pieter Hulshoff
participants (9)
-
BandiPat -
Carlos E. R. -
Dylan -
Felix Miata -
Jerry Feldman -
Pieter Hulshoff -
Randall R Schulz -
Stan Glasoe -
Sunny