All,

I have received an email from Bruce Allen (from Smartmontools page) this morning regarding this issue. His response to me is below.

**************************
Hi T-,

I just learned about this buzz from a colleague yesterday.

I don't have any experience with your Samsung drive. I suggest that you
run a sort self-test '-t short' and wait until it completes. The drive
age should then be shown in the self test log. Then experiment with the
different -v and -F options to see how the drive is storing its lifetime.

IMPORTANT INFORMATION BELOW: PLEASE PASS BACK TO THE UBUNTU COMMUNITY

I think that the -B value of 255 is incorrect. You should use 254 for
maximum performance. 255 IS DOCUMENTED AS 'RESERVED' IN THE ATA/SATA
SPECS. THE BEHAVIOR OF -B 255 THUS IS NOT PREDICTABLE AND IT MAY HAVE NO
EFFECT. Also according to the ATA/SATA specs any value greater than or
equal to 128 will 'not permit the device to spin down to save power'. So
128 will reduce power use as much as possible but not permit spin-down.

References:
http://www.t13.org/Documents/Uploade...7_Volume_1.pdf
PDF page 273 Document page 253
Table 43 (and the paragraph immediately following it).

So I suggest you try some different -B values such as -B 254 or -B 128.

The hdparm man page says 'values of 255 will disable Advanced Power
Management'. I think this is a mistake in the man page. According to the
ATA/SATA specs referenced above, the value 255 is reserved and has vendor
dependent meaning (or has no effect).

Cheers,
Bruce
***************************

I didn't have much time to experiment, but I did try the -B254 switch, and this did seem to work. Either I didn't try this number before, or I did, but still had power management enabled in the bios. Over the weekend, I will try the more permanent methods as suggested by Blackhole54.

Also, BlackHole54: I will read up on the vmstat command and see what that produces as well. Almost no question that my machine relies heavily on swap at the moment. I do what I can to reduce this by not running too many programs at once, until I get more RAM.

Ubuntu.michael: Before discovering that I had a problem of too many load cycles, I had to install the hdparm and smartmontools programs to a) display the information about the drive (via smartctl), and b)change the powersave options (via hdparm). Both of those utilities can be downloaded via the Adept or Synaptic package manager. You can also install the programs really quickly via the command line. You may have already figured this out, but if you need those instructions, post the request, and I can get that to you later when I am back on my linux box. I don't want to give you the wrong package name now and make things harder

tferero,

Thanks for doing this. Perhaps you tried 255 on your machine and it in fact did nothing while 254 works. On mine, I set it to 255, but when I subsequently read information back (capital I option) it reports 254. So this new info probably explains why I don't read back what I set.

I believe this reply is important and I will help propagate it by posting a link to your post #16 on my thread at UbuntuForums.

I also have some new info from experimenting. I booted my computer in Knoppix 5.1.1 which has smartctl. It does not use libata with my drive, so my drive registers as /dev/hdc rather than /dev/sda (don't ask me why it is on the second controller!). Also, by default, after it is booted, Knoppix will not be unexpectedly reading or writing to the disk. My BIOS leaves the parameter we've been talking about at 128. Under Knoppix I also tried 160 and 192. These were fairly quick tests and not at all systematic. But what I observed is consistent with the assertion that the disk won't spin down with a value of 128 (unless you also give it a spindown time with the -S option). What I found strange though -- and do not understand -- is at 128 and 160, when I gave it a
command, the load_count value incremented unless the commands were sufficiently quick (lack of time in between). This behavior seemed to stop at 192. So even though the disk was not spinning down, and even though I don't believe this command reads or writes to the actual drive platter(s), the load count was increasing.

EDIT: now that I think about it, the polling of the smartctl command may have been reading from the platter(s). So while not spinning down, my data would suggest the head still "unloads."

Some general comments on this thread.

First, you have to read smartctl output with a great deal of insight and care. Problem is that SMART isn't standardized among drive manufacturers, so different drives will report different things, and it is up to you, the user, to figure out what they mean on a per-drive basis.

Second, spinning a drive up and down 5 times a minute is most certainly excessive and must be having a negative impact on the system performance because the system has to wait while the drive spins up. However I am skeptical about it having such a severe impact on the drive's life expectancy. I understand the argument but I am not sure it is a correct one, and in any case I would expect it to vary from manufacturer to manufacturer.

It is true, however, that most drive manufacturers DO specify an expected number of start/stop cycles in their drive's life, but typically these are power cycles, not spin up/down cycles.

Third, laptop drives don't last long. They tend to run very hot given their environment and that harms them. Also, keep in mind that any spinning hard drive is a top - and you know how a top behaves when you try to reorient it. When your hard drive is spinning, do your best to avoid changing the orientation of the laptop; this puts large stresses on the platter, spindle, and bearings, and most certainly will shorten the drive life.

To make a hard drive in a laptop last, invest in a laptop cooler and to the extent possible run the laptop only on that cooler, sitting on a desk or table, and avoid reorienting it.

All,

More curious information: while the -B254 stops the spindown altogether, -B128 does not. I also tried -B129, and with both the latter values, I still spin down at about 5 times per minute. This is probably something specific to my samsung drive.

Also, setting the -B switch seems to be sticky; from one shutdown to the next (actually a couple shutdowns), the load cycles remained the same. That seemed odd, since this has been said to be a session-only fix. Not sure what to make of that, except to wait and watch. It wouldn't seem necessary to do a script if the value holds after shutting down and powering on.

Blackhole54, when I did the -I switch with hdparm, it read back APM as: unknown setting (0x00fe). Quirky drive I guess. Also, in your code line above you used "^193" -- why the ^ symbol? What does this do? I did this with my value (225) and the cycles went up by 2. Not sure what this is about.

Thanks.

I am definately outside any area of expertise I have, so take this as conjecture. But the -K option for hdparm is used to set or reset keep-features-over-reset. While it supposedly doesn't include -B (but does include a related option, -Z), maybe with your drives this variable will make -B persistent also. Then if the BIOS leaves -B alone on powerup, that would explain the behavior you see. As I say, just conjecture. In which case, whether to have a script run each time is up to you. Being the distrustful sort, I would be inclined to do it explicitly each time. Also note that this is peculiar to your machine. My machine does not exhibit this kind of persistence.

In case you are not aware, 0x00fe = 254. The "0x" indicates a hexadecimal number. I don't know why it says "unkown setting." Mine says:

(This is after I have rc.local set it.)

grep matches regular expressions. A caret (^) in a regular expression indicates the beginning of a line. So it won't match, for example, a line that just happens to have the string "193" as part of some value. If I wanted to allow for an arbitrary number (including zero) of spaces/tabs at the beginning of the line, I could have used "^[[:space:]]*193".

In post #17 I indicated that under some circumstances I saw the value increase by one with this test. Initially this baffled me as I believed the drive should not be accessing it platter(s). But then I decided that is this information is probably stored on the platter(s)!

Blackhole54, thanks for the clarification on the caret symbol. So much to learn...

Not sure what to think about the -B254 switch staying sticky either, just have to watch and see what it does.

Something else related to power management: I had two battery meter icons in my sys tray, which seemed odd. I explored this further, and realized I had two separate power management utils running simultaneously: Klaptop and Kde-guidance Power Manager. I have no idea which one was in control. I uninstalled the Klaptop, and one thing is for certain: my machine is running faster (not a lot, but what can one expect with 128MB of ram!).

In this regard, I am surprised upgrading to feisty didn't remove the Klaptop program automatically; from what I read, the Kde-guidance Power Manager is the new default app being used.

The one thing that isn't fully clear to me is where Power Manager ends and where hdparm starts, e.g., which one governs exactly what? I know that I have power management disabled in the files where it is supposed to be disabled, yet the drive still spun down. So, it would appear that Power Manager doesn't control disk spin-downs; only hdparm does.

I have read so much, it is becoming a mash in my head. If the inter-relationships of these power management utilities is clear to you or anyone reading this, please straighten me out, lol.

T.

I know the feeling! This morning I started to read through what ubuntu_demon describes as the "main thread" (30+ pages) for this issue on UbuntuForums. So far I've made it through the first 10 pages. Not sure what my retention of it is.

You are using an up-to-date Kubuntu and I am using a year old Ubuntu. On my software the desktop "power management" is the Gnome Power Manager. The only settings that this has is related to display (brightness & blanking) and if/when/how to suspend the computer or turn it off. With the arguable exception of suspend/off, these are things a user can rightly control -- i.e. you don't need root privilege. As far as spinning down the disk and the power management value for the disk goes, that all seems to be controlled with scripts and config files that only root can change.

Please see this bug report about the issue I highlighted in red above. It appears that hdparm (at least in the Ubuntu version -- can somebody verify it is in the upstream code as well?) treats the value of 255 differently and attempts to disable APM by a different mechanism.

EDIT: The "bug report" is not about a bug as much as suggesting the functionality of hdparm be altered to be more clear about what is happening.