Help with a seagate (SP6003H) hard disk issue (read only problem)

Ogi · 10-25-2006, 08:23 PM

Hi all, I have a strange problem with my Seagate hard disk which has been puzzling me for a while.

Basically, the drive seems to be locked read-only. Every write I do to it, it fails silently (no error messages, no hint whatsoever actually) but reads are fine.

for example, I delete a file, the next time I check the directory, its back there and complete.

Or if I use mkfs to make a new, clean fs on the disk. It says it was successfull (and no errors reported anywhere) but mounting it I get the old filesystem with all the files intact.

if I use dd (as in "dd if=/dev/zero of=/dev/hdb" or "dd if=/dev/urandom of=/dev/hdb") it again says successfull, but the drive still has the original data.

This has been bugging me for ages now, and I have no idea whats going on (I have never come across a problem like this before).

This is my biggest hard disk, and I would like to be able to re-use the space on it, so does anyone have any idea what I could do?

The disk has been tried in all sorts of different computers, and all gave the same reading.

(I was thinking that hopefully there is a way of re-setting the firmware on the disk, because I think this is some sort of in-built hardware failure protection or something, but feel free to provide any tips).

Thanks alot for any help!

Jaqui · 10-26-2006, 08:36 AM

and you are root when you are doing this?
no user but root has the rights to create a new filesystem.

and most likely the filesystem is locked from being changed by non root users is the cause of the issue you are described.

PTrenholme · 10-26-2006, 08:52 AM

Since you are getting no error messages, I'd be very surprised if it was a permissions problem.

Have you checked your BIOS settings? (Perhaps you've set a HD write protection password.)

Have you checked the drive jumper settings? (I don't actually think that they're any jumpers that could be set to do what you describe, but I could be wrong.)

Can you put the drive on a different cable/controller/computer to verify that you don't have a real hardware problem? (A second computer would be best, but swapping it with a drive that seem to work properly might tell you something.)

Note: Before swapping drives in a working system, you should set up udev and fstab to reference your drives by, e.g., serial number, so your system will work properly even when the physical drive positions are changed.

Dragineez · 10-26-2006, 08:53 AM

It may be that the drive is locked, preventing writes to the disc.

Quote:

What is a HDD Lock?
All hard disk drives have the possibility to set a hardware password, thus making the drive completely inaccessible unless a correct password is provided. When you set a password on your notebook, the notebook locks the drive as well. XBox gaming consoles and some desktop computers can also lock hard disk drives.

Ogi · 10-27-2006, 01:06 PM

Quote:

Originally Posted by PTrenholme

Since you are getting no error messages, I'd be very surprised if it was a permissions problem.

Unlikely, this was all done as root.

Quote:

Have you checked your BIOS settings? (Perhaps you've set a HD write protection password.)

The Drive was used in a USB enclosure, so no BIOS settings were used really.

Quote:

Have you checked the drive jumper settings? (I don't actually think that they're any jumpers that could be set to do what you describe, but I could be wrong.)

I had a look and didn't find any special "read only" jumpers. I tried setting all the jumpers (MASTER/SLAVE/CS) with no change.

Quote:

Can you put the drive on a different cable/controller/computer to verify that you don't have a real hardware problem? (A second computer would be best, but swapping it with a drive that seem to work properly might tell you something.)

As it was used in a USB enclosure, I tried on loads of computers. I also took out the drive and tried it in two of my Big PC's, with the same issue (was detected OK by the BIOS). I also tried the USB enclosure with another disk, with no problems.

Quote:

Originally Posted by Dragineez

It may be that the drive is locked, preventing writes to the disc.

Quote:

What is a HDD Lock?
All hard disk drives have the possibility to set a hardware password, thus making the drive completely inaccessible unless a correct password is provided. When you set a password on your notebook, the notebook locks the drive as well. XBox gaming consoles and some desktop computers can also lock hard disk drives.

It might be this, but I never set a password on the drive, and it has never prompted me for a password. But I would be willing, if for nothing else the ability to re-initialise the drive.

The Link you sent me was very useful, but the program is Windows only. As I have no windows system I don't want to have to go get a CD and install it just for the program. As such, does anyone know of any Linux-based programs which will do the same?

Thanks.

Dragineez · 10-27-2006, 02:59 PM

Quote:

Originally Posted by Ogi

It might be this, but I never set a password on the drive, and it has never prompted me for a password. But I would be willing, if for nothing else the ability to re-initialise the drive.

The Link you sent me was very useful, but the program is Windows only. As I have no windows system I don't want to have to go get a CD and install it just for the program. As such, does anyone know of any Linux-based programs which will do the same?

Thanks.

Sounds more and more like a hardware write block to me. Makes sense if you think about it. It only has to open the circuit on two pins on the IDE bus and the drive will behave normally in all respects - except for writes. Until that circuit is closed and those pins enabled, nothing short of a Sharpie will write to it. Have you tried the driver manufacturer for something like a BIOS or firmware reset utility? If it exists, it's probably something that could be run from a DOS boot floppy - and you could use FreeDOS for that.

Ogi · 10-27-2006, 07:56 PM

Quote:

Originally Posted by Dragineez

Sounds more and more like a hardware write block to me. Makes sense if you think about it. It only has to open the circuit on two pins on the IDE bus and the drive will behave normally in all respects - except for writes. Until that circuit is closed and those pins enabled, nothing short of a Sharpie will write to it.

Sounds very interesting, Where can I find out more about this? Which two pins cause this? And when you say there is an "open ciruit", does this mean that there is some physical damage to the logic board? (e.g. severed connections/tracks on the PCB?) Or is this more of a firmware/software issue?

Quote:

Originally Posted by Dragineez

Have you tried the driver manufacturer for something like a BIOS or firmware reset utility? If it exists, it's probably something that could be run from a DOS boot floppy - and you could use FreeDOS for that.

I found some util exe on the Seagate site which are for DOS, I will give it a go when I get access to the drive again.

Thanks alot for the help

Dragineez · 10-29-2006, 12:16 PM

Quote:

Originally Posted by Ogi

Sounds very interesting, Where can I find out more about this? Which two pins cause this? And when you say there is an "open ciruit", does this mean that there is some physical damage to the logic board? (e.g. severed connections/tracks on the PCB?) Or is this more of a firmware/software issue?

This is how forensic write blockers work. Since we know this drive has blocking capability, all that need be done is for a simple firmware controlled logic circuit to remain open on the write pins to prevent all writes. The drive manufacturer's utility merely allows you to close that circuit to permit writes.

Ogi · 10-29-2006, 06:27 PM

Well,

Ran the disk util software, and did a diagnostics check, all tests were ok except one, which read: "Write Verify: FAILED" (this I presume works like the badblocks program, when run in write mode, it writes to a block a known value, then compares it).

After that I ran both a low-level format followed by a normal "erase" cycle. Both said they sucessfully completed, but when I boot back into linux I get the fs with all my files back again

What is interesting is that while the "Write Verify" failed, the simple read/write test passed with no problems.

Any ideas?

Ogi · 10-30-2006, 06:07 AM

I Also have some information regarding the device here if it will help:

Code:

/dev/hdb:

ATA device, with non-removable media
	Model Number:       SAMSUNG SP6003H                         
	Serial Number:      XXXXXXXXXXXXXX      
	Firmware Revision:  QV100-61
Standards:
	Used: ATA/ATAPI-6 T13 1410D revision 1 
	Supported: 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:  117304992
	device size with M = 1024*1024:       57277 MBytes
	device size with M = 1000*1000:       60060 MBytes (60 GB)
Capabilities:
	LBA, IORDY(cannot be disabled)
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Recommended acoustic management value: 128, current value: 0
	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
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set
	   *	Mandatory FLUSH_CACHE
	   *	SMART error logging
	   *	SMART self-test
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	72min for SECURITY ERASE UNIT. 72min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
	CBLID- above Vih
	Device num = 1 determined by the jumper
Checksum: correct

And this is the output of the hard disks Error Log (via smartctl):

Code:

smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
Warning: ATA error count 23044 inconsistent with error log pointer 5

ATA Error Count: 23044 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 23044 occurred at disk power-on lifetime: 27922 hours (1163 days + 10 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 16 07 be 80 f0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 03 16 07 be 80 f0 00  48d+07:26:31.680  SET FEATURES [Set transfer mode]
  e7 00 00 00 00 00 f0 00  26d+10:47:24.160  FLUSH CACHE
  ec 00 00 07 be 80 f0 00  31d+02:33:55.200  IDENTIFY DEVICE
  e7 00 00 00 00 00 f0 00  46d+16:46:32.960  FLUSH CACHE
  ec 00 00 ab 81 cc f0 00  46d+16:46:32.960  IDENTIFY DEVICE

Error 23043 occurred at disk power-on lifetime: 27922 hours (1163 days + 10 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 05 01 00 00 b0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  a1 00 05 01 00 00 b0 00  48d+04:31:42.080  IDENTIFY PACKET DEVICE
  ca 03 08 3f 74 04 e2 00      03:38:13.631  WRITE DMA
  ca 03 08 4f ec 00 e1 00      03:38:13.631  WRITE DMA
  ca 03 08 ef 01 ea e0 00      01:21:41.631  WRITE DMA
  ca 03 18 d7 01 ea e0 00      01:21:41.631  WRITE DMA

Error 23042 occurred at disk power-on lifetime: 15890 hours (662 days + 2 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 08 00 00 00 e0  Error: ICRC, ABRT 8 sectors at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 03 08 00 00 00 e0 00   3d+06:39:04.960  READ DMA
  ef 03 42 01 00 00 e0 00   3d+06:39:04.960  SET FEATURES [Set transfer mode]
  ef 03 0c 01 00 00 e0 00   3d+06:39:04.960  SET FEATURES [Set transfer mode]
  00 00 01 01 00 00 00 00   3d+06:39:04.960  NOP [Abort queued commands]
  00 00 01 01 00 00 00 00   3d+06:39:04.960  NOP [Abort queued commands]

Error 23041 occurred at disk power-on lifetime: 15890 hours (662 days + 2 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 08 00 00 00 e0  Error: ICRC, ABRT 8 sectors at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 03 08 00 00 00 e0 00  43d+13:51:12.640  READ DMA
  ec 03 42 01 00 00 e0 00  43d+13:51:12.640  IDENTIFY DEVICE
  ef 03 42 01 00 00 e0 00  17d+03:42:06.080  SET FEATURES [Set transfer mode]
  ef 03 0c 01 00 00 e0 00  17d+03:42:06.080  SET FEATURES [Set transfer mode]
  00 00 01 01 00 00 00 00  17d+03:42:06.080  NOP [Abort queued commands]

Error 23040 occurred at disk power-on lifetime: 4626 hours (192 days + 18 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 f0 af e8 c1 e1  Error: ICRC, ABRT at LBA = 0x01c1e8af = 29485231

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ca 03 f0 af e8 c1 e1 00  45d+03:25:09.760  WRITE DMA
  ca 03 f0 bf e8 c0 e1 00  45d+03:25:09.760  WRITE DMA
  ca 03 68 f7 e8 bf e1 00  45d+03:25:09.760  WRITE DMA
  ca 03 f0 07 e8 bf e1 00  45d+03:25:09.760  WRITE DMA
  ca 03 f0 17 e8 be e1 00  45d+03:25:09.760  WRITE DMA

Reading this, I have to say, 23044 errors is a lot. From what I have gathered it seems the main Error is when DMA Writing (looks like the drive writes data, then reads back and checks using CRC if the data was correctly written. If not, it then aborts).

Can someone more knowledgable shed some more light on this? What is this drives problem?

Thanks.

czapa_ols · 01-14-2007, 04:43 PM

As it was in post above:
>>Security:
>> Master password revision code = 65534
>> supported
>> not enabled
>> not locked
>> not frozen
>> not expired: security count
>> no not here supported: enhanced erase
>> 72min for SECURITY ERASE UNIT. 72min for ENHANCED SECURITY
>> ERASE UNIT.

OGI, I don`t know how, but you have enabled a security erase, and as you can see above U need to wait 72min after erasing data for data to be erased

Currently I have not found secure tool to disable this "support".
But read: hdparm --security-help
it may help but can also ?destroy? your drive.