5

I have an old disk that often gets stuck in some form of loop, and often I need to perform a full reboot to get it "unstuck", whereupon I had found out about the hdparm -w command. However, its manpage lists this command as dangerous:

-w

Perform a device reset (DANGEROUS). Do NOT use this option. It exists for unlikely situations where a reboot might otherwise be required to get a confused drive back into a useable state.

What are the dangers, and do they exceed the dangers of data loss due to a hard-reboot?

slhck
  • 223,558
  • 70
  • 607
  • 592
nanofarad
  • 610
  • 1
  • 7
  • 21
  • 2
    The dangers of `hdparm -w` aside, if your drive requires extra measures of *any* kind, the only thing left to do is to back up the data and replace the drive. Non-negotiable. – DevSolar Jul 20 '12 at 15:01
  • 1
    @DevSolar It's an old drive being mounted as /tmp and I am too cheap to get a drive right now... – nanofarad Jul 20 '12 at 15:03
  • 1
    Even if it is "only" /tmp, a storage device that does not work flawlessly always poses imminent danger of irrecoverable data loss. If that doesn't bother you, use `hdparm -w` and don't worry because dangers obviously don't matter. If you *do* care for your data, replace the drive. – DevSolar Jul 20 '12 at 15:07
  • 2
    OK. I still would like to know about the command's dangers. – nanofarad Jul 20 '12 at 15:10
  • I assume much of the danger implied by the `hdparm` man page arises from file systems not properly unmounted, certain drive's firmware not responding to a soft reset properly etc.; as I said, if you don't give a damn, go right ahead. ;-) – DevSolar Jul 20 '12 at 15:10
  • What exactly can break in a Linux system after hdparm -w? And what is the minimal sufficient thing to avoid the dangers? (E.g., remounting read-only all filesystems would be enough. Or going into runlevel 1. Or what?) – imz -- Ivan Zakharyaschev Jul 29 '14 at 17:32

1 Answers1

1

You don't want to issue the command while any filesystem using that drive is mounted, or a read/write operation is in progress, obviously.

However, if your drive got stuck during a read/write operation, and a kernel operation is blocked as a result (the involved process will be in D state according to ps) I imagine you might cause an unexpected condition (i.e. possibly a kernel panic) if you send this command.

You also probably might do something weird to the drive if you issue this command while the drive is busy doing something else (like a firmware update), though I don't know that for a fact. Some drive firmwares may have bugs that cause weirdness in this case.

LawrenceC
  • 73,030
  • 15
  • 129
  • 214