About:
hdparm is a Linux shell utility for viewing and manipulating various IDE drive and driver parameters. Most drives can benefit from improved performance using a command similar to "hdparm -qm8 -qu1 -qc1 -qd1 /dev/hda".

Release focus: Minor feature enhancements

Changes:
This version is compatible with /sys/block/ symlinks, as seen on some distributions' kernels.

Author:
Mark Lord [contact developer]

Rating:	reset 1 2 3 4 5 6 7 8 9 10
8.66/10.00 (15 votes)

Homepage:
http://sourceforge.net/projects/hdparm/
Changelog:
https://sourceforge.net/[..]es.php?release_id=638207&group_id=136732

Trove categories: [change]

[Development Status]		6 - Mature
[Environment]		Console (Text Based)
[Intended Audience]		System Administrators
[License]		Freely Distributable, OSI Approved :: BSD License (original)
[Operating System]		POSIX :: Linux
[Programming Language]		C
[Topic]		System :: Hardware, Utilities

Dependencies: [change]
No dependencies filed

 Branches

Branch	Version	Last release	License	URLs
Default	9.3	11-Nov-2008	BSD License (original)

 Releases

Version	Focus	Date
9.3	Minor feature enhancements	11-Nov-2008 21:57
8.9	Minor feature enhancements	21-Jun-2008 13:12
8.8	Minor bugfixes	15-Jun-2008 12:22
8.6	Minor feature enhancements	15-May-2008 11:45
8.5	Major security fixes	25-Feb-2008 01:43
8.1	Major feature enhancements	17-Feb-2008 21:24
6.9	Minor feature enhancements	17-Jan-2007 19:10
6.6	N/A	08-Mar-2006 14:58
6.5	Minor bugfixes	01-Mar-2006 14:42
6.3	N/A	24-Oct-2005 12:35

 Comments

[»] How to erase the whole disk ?
by Lotje - Jul 16th 2008 10:55:49

Hi all,

Since quite a while I want to erase my harddisk on the secure erase method. hdparm supports
this, but I always get the same error 5.

I use version 6.9

root@Knoppix:/media/hda1# hdparm -V
hdparm v6.9

The first thing I do is ask some info about the disk:

root@Knoppix:/media/hda1# hdparm -I /dev/hda

/dev/hda:

ATA device, with non-removable media
Model Number: SAMSUNG SP0411N
Serial Number: S01JJ50X351236
Firmware Revision: TW100-11
Standards:
Used: ATA/ATAPI-7 T13 1532D revision 0
Supported: 7 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78165360
device size with M = 1024*1024: 38166 MBytes
device size with M = 1000*1000: 40020 MBytes (40 GB)
Capabilities:
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
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=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
* Power Management feature set
* Write cache
* Look-ahead
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* SMART error logging
* SMART self-test
Security:
Master password revision code = 65534
16min for SECURITY ERASE UNIT. 16min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by CSEL
Checksum: correct


It looks that my disk supports enhanced security erase. Now I set the password, but
this already fail:

root@Knoppix:/media/hda1# hdparm --security-set-pass test /dev/hda

/dev/hda:
Issuing SECURITY_SET_PASS command, password="test", user=master, mode=high
Problem issuing security command: Input/output error
Error: 5

Then I tried to unlock, but because the password setting failed, this doesn't work either.

root@Knoppix:/media/hda1# hdparm --security-unlock test /dev/hda

/dev/hda:
Issuing SECURITY_UNLOCK command, password="test", user=master
Problem issuing security command: Input/output error
Error: 5

And the erase also give an error:

root@Knoppix:/media/hda1# hdparm --security-erase test /dev/hda

/dev/hda:
Issuing SECURITY_ERASE command, password="test", user=master
HDIO_DRIVE_CMD(erase prepare) failed: Input/output error

Can somebody help me to work this out ?

Thanks a lot,

Lotje

[reply] [top]

[»] Re: How to erase the whole disk ?
by Mark Lord - Jul 28th 2008 20:46:34

I believe you are doing the right sequence of steps, so the problem is likely a broken kernel call in the old IDE drivers. I do know that there are bugs in the kernel ioctls() HDIO_DRIVE_TASK and HDIO_DRIVE_TASKFILE have bugs in some scenarios, with the old IDE drivers. So that is what is probably causing it not to work for you. If you need this kind of functionality, your best bet is to switch over to the modern libata kernel drivers, which are replacing the old IDE ones. The libata kernel drivers fully support hdparm and the SECURITY_ERASE functionality. Cheers

[reply] [top]

---

[»] does anyone know how to unlock a hdd via ide-over-usb?
by Ralf - Feb 9th 2008 11:54:09

see the following command, the kernel flag is definitely compiled in, but hdparm seems to not recognize. Probably this is related to the fact that the HDD is connected via a USB case and therefore is a scsi disk for the OS - is this correct? Any workarround? I already tried blktool out of the gkernel project or sdparm but both seem to lack the ability of sending ATA security commands (e.g. --security-unlock)



gbox / # gunzip </proc/config.gz |grep -i task_ioctl;hdparm --security-unlock pass /dev/sdb
CONFIG_IDE_TASK_IOCTL=y
security_password="pass"

/dev/sdb:
Issuing SECURITY_UNLOCK command, password="pass", user=master
The running kernel lacks CONFIG_IDE_TASK_IOCTL support
SECURITY_UNLOCK: Invalid argument

[reply] [top]

[»] Re: does anyone know how to unlock a hdd via ide-over-usb?
by Russell - Mar 3rd 2008 10:17:59

I have confirmed that I see identical behavior with hdparm. If anyone has any information please post. Until then I'll investigate . . .


> see the following command, the kernel

> flag is definitely compiled in, but

> hdparm seems to not recognize. Probably

> this is related to the fact that the HDD

> is connected via a USB case and

> therefore is a scsi disk for the OS - is

> this correct? Any workarround? I already

> tried blktool out of the gkernel project

> or sdparm but both seem to lack the

> ability of sending ATA security commands

> (e.g. --security-unlock)

>

>

>

>

> gbox / # gunzip </proc/config.gz

> |grep -i task_ioctl;hdparm

> --security-unlock pass /dev/sdb

> CONFIG_IDE_TASK_IOCTL=y

> security_password="pass"

>

> /dev/sdb:

> Issuing SECURITY_UNLOCK command,

> password="pass", user=master

> The running kernel lacks

> CONFIG_IDE_TASK_IOCTL support

> SECURITY_UNLOCK: Invalid argument

>

>

>



[reply] [top]

---

[»] sata drive usage?
by waltermh - Jun 27th 2005 11:53:24

is hdparm useful with sata drives, does it work with sata drives?

when i try hdparm -d /dev/sda i get
[root@localhost ~]# hdparm -d /dev/sda

/dev/sda:

so i cant tell if its off or on, doing hdparm -v -I /dev/sda gets me this:
[root@localhost ~]# hdparm -v -I /dev/sda

/dev/sdc:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 30515/255/63, sectors = 251000193024, start = 0
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device

I dont get that last part, when i try hdparm on my ata drive i can get all info.

[reply] [top]

[»] Re: sata drive usage?
by Mark Lord - Jun 27th 2005 12:15:24


> is hdparm useful with sata drives, does

> it work with sata drives?

SATA drives in the 2.6 kernel are handled by the new "libata" SCSI driver. If you add the "ATA passthru" patch (from Jeff Garzik) to your kernel, then hdparm can work with those drives.

Some flags, like "-d", are not supported by libata. Currently, ALL SATA hard drives use DMA, so there is no need for -d. But eventually libata will have to implement ATA PIO (for CF cards..), and at that time it may (or not) begin to support the "-d" flag.

[reply] [top]

---

[»] Re: sata drive usage?
by waltermh - Jun 27th 2005 12:26:58

thanks will try google for that patch i guess, never patched a kernel before i have seen people online get numbers from -tT option for sata around 1000+ for cache, and 100+ for buffer, and i am getting 520-530 and 50-65 respectively i am testing on 2 drives that dont do anything but hold backup files getting 60-65 buffer, and my main drive getting 54 buffer, of course testing multiple times, just hoping i can get numbers higher io support is at 16 bit default, i get an error when switching to 32bit, is that one of those currently unsupported features?

[reply] [top]

---

[»] Re: sata drive usage?
by Mark Lord - Jun 27th 2005 12:38:39

If "hdparm -I /dev/sda" works (uppercase -I), then your kernel already has the passthru patch. The I/O 16 bit only applies to non-DMA IDE drives. Since SATA drives all use DMA, that setting doesn't matter and is not supported by libata. About the only flags you can play with to improve things are the "-A" (read-ahead) and "-W" (write-caching). A few people think -W1 is a bad idea, but as a kernel developer I generally crash my machine daily, and -W1 has never cost me any data while saving me hours of time (it really speeds up many machines). Cheers

[reply] [top]

---

[»] hdparm -Tt benchmark statistics
by jago25_98 - Dec 3rd 2004 05:21:10

Anyone know of a site with hdparm benchmarks?

What do you get?

- post it here!

[reply] [top]

[»] registering IF by hdparm with no device
by olecom - Jun 9th 2003 18:00:53

I noticed, that `hdparm -R` (and -U) works after checking(opening) of /dev/hd??. Today, I sat on nfs_root with no /dev/hda, and wanted to register it, after I inserted hdd into mobile rack and this *feature* failed to do it, because I have no /dev/hd* at all.

In hdparm.c "#ifdef HDIO_SCAN_HWIF && #ifdef HDIO_UNREGISTER_HWIF" are stand after "fd = open (devname, O_RDONLY|O_NONBLOCK);"
and use fd from it: "if (ioctl(fd, HDIO_UNREGISTER_HWIF, hwif))..."
what if to patch this *thing* with: "if (ioctl(0, HDIO_UNREGISTER_HWIF, hwif))" ?
I think it is solution.

thanks, GL.

[reply] [top]

[»] Re: registering IF by hdparm with no device
by Mark Lord - Jun 9th 2003 20:13:40

My brain cells are unable to decipher the previous message. Care to try again? :)

[reply] [top]

---

[»] Re: registering IF by hdparm with no device
by olecom - Jun 11th 2003 14:55:23


> My brain cells are unable to decipher
> the previous message. Care to try again?
> :) Sorry for that, I'll try.
I have little problem. I want to use IDE hotswap with Linux. I think I'am rihgt, when use `hdparm -R` and `hdparm -U` for it.
Stability for this process gives Linux 2.4.21rc1-ac2
(o Fix the ide unregister deadlock bug (me))
It works well. But if there is no IDE device at all, for example on NFS root, I can not register new one:
debian:~# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / nfs rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=10.33.12.152 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
debian:~# ls /proc/ide/
drivers
debian:~#
++++++ I tried:
debian:~# hdparm -R 0x170 0 0 /dev/hdc
/dev/hdc: No such device or address
debian:~# hdparm -R 0x170 0 0 /dev/hda
/dev/hda: No such device or address
debian:~# hdparm -R 0x170 0 0 /dev/zero
/dev/zero not supported by hdparm
debian:~#

If it not so hard for You to fix this problem, do that please.

P.S I used to do it by myself, but Linux's ioctl() don't want to do my buggy hacks like fd == 0, or fd = open ("/dev/zero"...)
;-)

Many thanks.


[reply] [top]

---

[»] Re: registering IF by hdparm with no device
by olecom - Jun 17th 2003 01:45:02

was it clear ? will you write a patch, or this is impossible ? thanks

[reply] [top]

---

[»] Re: registering IF by hdparm with no device
by Mark Lord - Jun 17th 2003 05:39:09


> was it clear ?
> will you write a patch, or this is
> impossible ?
>
> thanks
>
I don't think it is possible to "fix" this without patching the driver (kernel), and that is not going to happen until the IDE driver is updated completely (2.5.xx) to handle hotswap.

But.. if there are no drives/interfaces currently registered, then you should be able to "rmmod" the ide driver modules, and then "modprobe" them again -- when they are reloaded they will probe and find your drive.

Cheers

[reply] [top]

---

[»] unregistering / registering IF by hdparm - kernel prereq?
by John Lumby - Mar 4th 2004 19:26:35

I am new to this. I have a laptop (IBM thinkpad) with ultrabay, and have a floppy drive and hard-drive-adapter which it can accept. I'd like to be able to hotswap them in and out as Windows can. I am running RH9 with a 2.4.20 kernel. I build hdparm 5.5 and after unmounting all partitions on my /dev/hdc, I tried hdparm -U 1 /dev/hdc (Based on the code in the contrib/idectl) it replied /dev/hdc: attempting to unregister hwif#1 but I can't pull the drive adapter and e.g. dd can still read the partitions. I assume it was not successful. Do I need a newer kernel? 2.6.? Also, I believe there is a bug in the contrib/idectl: it has USE_IDE_DEV_0=/dev/hdc USE_IDE_DEV_1=/dev/hda This looks the wrong way round to me, e.g. my dmesg says: ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15

[reply] [top]

---

[»] Do NOT enable -W1! DO USE -W0 instead!
by Matthias Andree - May 29th 2002 08:47:05

The -W1 switch enables the write cache of a hard disk and will cause severe file system corruption in face of a power outage that occurs while a write operation is in progress. Journalling file systems (reiserfs, ext3fs, xfs, jfs, you name it) cannot help about this either, but may instead hide the actual problem. These file systems rely on their write operations being performed in order.

However, most IDE drives ship with write caches enabled to cheat benchmarks, at the expense of data safety.
Use hdparm -W0 on all your drives to turn the write cache off.

If your drive supports tagged command queueing, it will help write performance as soon as support for this feature gets into your kernel. Tagged Command Queueing makes the write cache safe.

Write barrier support patches are also circulating and may help safety, but before these are in you kernel, enabling the write cache or leaving it enabled without using tagged command queueing is UNSAFE.

You have been warned.

--
-- Matthias Andree

[reply] [top]

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Mark Lord - May 29th 2002 09:09:28

There is small (VERY SMALL) potential for losing a disk write on sudden powerfail with the drive caching enabled. But this is so small as to be insignificant for nearly all of us, and enabling the write cache does FAR MORE than just "cheat benchmarks" -- it really does improve system response and throughput quite noticeably. I use -W1 continuously during kernel development, with extremely frequent crashes and have never, ever, lost even a sector of data. So while the possibility exists, say about the same as contracting a flesh-eating disease, in reality -W1 is safe for the rest of us, and really speeds up the system. The poster above is more than welcome (hey, even encouraged!) to stick with the slow -W0 lifestyle. But life is too short for me to wait that much for my computer. Cheers

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Scott Weikart - Dec 11th 2003 11:43:06


> There is small (VERY SMALL) potential
> for losing a disk write on sudden
> powerfail with the drive caching
> enabled. But this is so small as to be
> insignificant for nearly all of us ...

Why do you say the probability is insiginificant? Maybe you don't have an environment with unreliable power?


> enabling the write cache does FAR MORE
> than just "cheat benchmarks" -- it
> really does improve system response and
> throughput quite noticeably.

Once we have TCQ, enabling the disk's write cache *should* not affect performance.


> I use -W1 continuously during kernel
> development, with extremely frequent
> crashes and have never, ever, lost even
> a sector of data.

A crash has no relationship to a power failure.

If you want to test power failures, you should try pulling out the power cord during heavy write activity (with modern motherboards, I no longer understand what the power switch does).

-scott

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Xose - Dec 13th 2003 18:08:28


>
> % There is small (VERY SMALL) potential
> % for losing a disk write on sudden
> % powerfail with the drive caching
> % enabled. But this is so small as to be
> % insignificant for nearly all of us ...
>
> Why do you say the probability is
> insiginificant? Maybe you don't have an
> environment with unreliable power?


write back cache ON is not recommended, there are a lot of literature about that:



http://listman.redhat.com/archives/ext3-users/2003-February/msg00109.html
http://sr5tech.com/write_back_cache_experiments.htm
http://sr5tech.com/download/ATA_RAID5_Whitepaper.pdf
http://archives.postgresql.org/pgsql-admin/2000-12/msg00094.php
http://redhat.com/archives/fedora-test-list/2003-November/msg01447.html
http://redhat.com/archives/fedora-test-list/2003-December/msg00001.html
http://marc.theaimsgroup.com/?t=104991701200010&r=1&w=2
http://marc.theaimsgroup.com/?t=107014526000001&r=2&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=106745860511194&w=2

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Alexander - Nov 14th 2005 07:54:59


> If your drive supports tagged command

> queueing, it will help write performance

> as soon as support for this feature gets

> into your kernel. Tagged Command

> Queueing makes the write cache safe.

> Write barrier support patches are also

> circulating and may help safety, but

> before these are in you kernel, enabling

> the write cache or leaving it enabled

> without using tagged command queueing is

> UNSAFE.

>

To me it seems that TCQ, NCQ and any write reordering CQ preserves the problem.

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Alexander - Dec 30th 2005 03:04:46


> To me it seems that TCQ, NCQ and any
> write reordering CQ preserves the
> problem.
Ok. I've done some tests.
You can see how important is write cache for performance here.

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Alexander - Feb 24th 2006 03:03:31

I moved my page here.

[reply] [top]

---

[»] Re: Do NOT enable -W1! DO USE -W0 instead!
by Alexander - Feb 24th 2006 03:07:29

Sorry for dublicate postings. My page is now here. If some moderator combine the posts it will be good...

[reply] [top]

---

[»] Compile does not work with new Kernel 2.4.1
by roalter - Feb 21st 2001 04:03:12

Everytime I try to compile it, I get an error saying some variable is not defined in /usr/include/linux/strings.h Are there some major changes in the new kernel?

[reply] [top]