Mayuresh wrote:
> Bob Proulx wrote:
> > hdparm -B /dev/sda
>
> /dev/sda:
> APM_level = 128
man hdparm
-B Get/set Advanced Power Management feature, if the drive supports
it. A low value means aggressive power management and a high
value means better performance. Possible settings range from
values 1 through 127 (which permit spin-down), and values 128
through 254 (which do not permit spin-down). The highest degree
of power management is attained with a setting of 1, and the
highest I/O performance with a setting of 254. A value of 255
tells hdparm to disable Advanced Power Management altogether on
the drive (not all drives support disabling it, but most do).
I admit I am not sure but I think 128 as above won't force a spindown
and therefore doesn't seem to be the link for head parking. I look at
a few of my systems and they either have 128 or off depending upon the
drive. The ones with 128 have a moderate load cycle count in the low
hundreds. Therefore I would normally say that is okay.
But you said you saw it increasing on your system and it was in the
thousands. Therefore I would be inclined to suggest that it should be
disabled on your system.
# hdparm -B255 /dev/sda
Or if you like turn power management to the lowest level. Since it is
a laptop I would tend to use the 254 conservative figure.
# hdparm -B254 /dev/sda
> If I can at least ascertain that the issue is with the drive, I can try
> and get it replaced in warranty. I am unsure since the laptop came with
> FreeDOS and when booting on FreeDOS there is no disk noise. So difficult
> to convince the retailer that there is an issue with the drive.
You only reported a load_cycle_count in the thousands. Before this
problem was well known I had drives in the hundreds of thousands.
Some of those are still running fine. I wouldn't worry about it. But
I would prevent it from getting worse.
Note one crazy thing. I have an SSD that reports a load cycle count
in the 335738 range. Obviously there isn't any head to park and it is
simply reporting the number of times it would have parked if it were a
spinning hard drive with a head. For anyone who looks at an SSD and
depending upon the firmware might get spooked it isn't a worry there.
> > What does it indicate. It was 3755 when I started the system today and
> > growing over a few minutes.
>
> I got what it indicates. It's scary...
At 3755 I wouldn't worry. Drives are rated in the hundreds of
thousands. Your drive is still young by the metrics.
> I noticed utilities to "fix" this problem in the wd drives. I checked my
> drive, it is:
>
> ata1.00: ATA-9: HGST HTS545050A7E680, GR2OA350, max UDMA/133
>
> So, not sure whether there exists a utility to fix its head parking
> problem. Also not clear, why I don't get that noise when booting to
> FreeDOS.
It depends upon many things. Configuration and use patterns. It may
not be a problem under FreeDOS. In any case for this particular issue
it is easy to fix.
You already have hdparm installed. There are multiple ways to
configure hdparm to set the -B option automatically. The config file
/etc/default/hdparm is probably best for you. This configuration will
set it for you at boot time.
harddisks="/dev/sda"
hdparm_opts="-B254"
As long as I am talking I will mention that I have a couple of drives
that require this. But I didn't want to set it for all drives.
Therefore for me on my servers where I have automated configuration to
detect and configure these things I set up the following section in
the /etc/hdparm.conf file.
/dev/disk/by-id/scsi-SATA_ST2000DM001-1CH_S1E14TKT {
apm = 254
}
With that in place hdparm sets it only for that one specific disk
drive and serial number combination. It doesn't get set for other
disks that don't need it. Plus since I have dynamic system
configuration if I move the drive from one system to another my config
scripts move the configuration to follow the drive. That is a whole
different topic but basically something like puppet, chef, and so forth.
> It is static and mostly off. I can keep it on if needed. It doesn't have
> to move around. But isn't there something I can run one time to know the
> issue.
I would be inclined to write a short script that is run from the
cron.daily run from anacron that checks if on_ac_power is true before
running and if so then 'smartctl -t short /dev/sda' so that a short
selftest is run daily. Then do the same in cron.weekly so that weekly
a 'smartctl -t long /dev/sda' is run. That way the internal disk
firmware selftests will be run periodically. The anacron will ensure
that it gets run with the other housekeeping tasks. The check through
on_ac_power will ensure that it doesn't happen when the system is off
mobile on battery. Since I am not doing this myself I will leave that
as an exercise for the reader. :-)
Bob
Attachment:
signature.asc
Description: Digital signature