Branches
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]
|
