Tech Support Forum banner
Status
Not open for further replies.

Bizarre bad sector behaviour on 4TH Seagate drive

3K views 17 replies 5 participants last post by  VanderveckenSmi 
#1 ·
Hi folks, I have a 4TB Seagate drive I've been using as a backup. It's in an external enclosure with eSata and USB 3.0. Recently I plugged it in via eSATA to my Ubuntu 14.04 system and ran badblocks. I was overwhelmed with bad sectors. dmesg was full with lines like this: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK and end_request: I/O error, dev sdb, sector There were so many that kern.log and syslog filled the entire (small) OS drive. So I thought the HDD was hosed. I took it to my Windows system, which could not read ext4, so I formatted it and ran chkdsk on the now NTFS drive. No bad sectors. I'm running badblocks again, plugging the drive in via USB, still no bad sectors. I don't understand why I would get I/O errors for some sectors in badblocks, but reformatting the drive and connecting via USB instead of eSATA would result in no bad sectors. Does this make sense to anyone? Thanks, Vandervecken
 
#2 ·
Hi VanderveckenSmi,


I would recommend running a brand specific diagnostics tool on the drive. Post the SMART status here after the extended test. There are different diagnostics tools, however, the once from the manufacturer usually provide the most accurate results as they know the firmware best. Other than, it is possible the detected bad sectors were software related and not physical. In that case a format or low level format (writing zeroes) could help. Still, if you have important information on the drive back it up, just to be on the safe side. Not to mention it is recommended to always have (two) backups of your data, ideally stored in different locations. Either way, do post a screen of the SMART status of the drive here ;)


Keep me posted,
Frost_WD
 
#5 ·
I should note, this has happened on two drives. Both Seagate ST4000DM000 drives. Both showing the same failures. I haven't gotten to reformatting and testing the second one, but that means that if we want to investigate these r/w errors, I still have drive that I think I can make that happen on.
 
#9 ·
@VanderveckenSmi, ISTM that your testing is indicating a problem with the setup rather than the HDD.

I would examine sector 0 with a disc editor (eg DMDE freeware). Some enclosures are configured with 4KB sector sizes via USB (but not via SATA) while others have 2TiB limitations via USB but not via SATA. I would do this both via SATA and USB.

If you have created an NTFS volume, the following command should report the logical and physical sector sizes of the bridge firmware:

fsutil fsinfo ntfsinfo X:

... where X: is the drive the letter.

BTW you can use Linux Reader for Windows to mount Linux file systems.
 
#11 ·
To some of the points so far:
The drives originally had some weird MBR-based setup, so I wrote a GPT to them and formatted as a single ext4.
I removed them from the original enclosure entirely and put them in an enclosure bought separately. This enclosure should have nothing more complex than an eSATA/USB connector. All the complex crap that it came with is gone.

I still have one of the drives that I haven't written over. I will try to run badblocks on it again and see what comes out in more detail.
 
#13 ·
To some of the points so far:
The drives originally had some weird MBR-based setup, so I wrote a GPT to them and formatted as a single ext4.
I removed them from the original enclosure entirely and put them in an enclosure bought separately. This enclosure should have nothing more complex than an eSATA/USB connector. All the complex crap that it came with is gone.
Unfortunately it appears that the "complex crap" was configured with 4KB sectors. That's how a 2TiB+ drive can be made to overcome the 32-bit LBA limitation of MBR partitions. After transferring such a drive to your new enclosure, you would end up with a 4Kn file system on a 512e USB mass storage device. That's why your data were inaccessible. If you reinstall your drive inside its original enclosure, then your data will be accessible once again (unless you have reformatted it).
 
#12 ·
Hi VandervechkenSmi,


Could you please run the brand specific diagnostics tool on the drives? As said above usually the tool developed from the manufacturer yields the most accurate results. Post a screenshot when you have completed the extended test ;). Can you tell us if there were any symptoms, such as hang-ups, long booting times, etc.?
As suggested above, you could check the warranty policy of your brand, however, I doubt that you can ask for an RMA, since removing the enclosure usually voids the warranty.
I would suggest connecting the drive internally and checking if they work properly. @fzbkar gave you some good advice so could you check out his suggestion and report back.


Keep us posted,
Frost_WD
 
#15 ·
Can you tell us anything more about your enclosures? What "complex crap" are you referring to?

One other problem that shows up in the storage forums is 32-bit LBA limited USB enclosures. Such an enclosure will identify a 4TB drive as having a capacity of 1.8TB / 1.64TiB (= 4TB - 2TiB). However, the eSATA port on such an enclosure won't be affected by such a limitation since the data path between the HDD and the OS doesn't go through the bridge firmware. Switching between the two interfaces can result in strange problems, even data loss.

The same problem arises when a user partitions and formats the drive internally via a SATA port on the computer's motherboard and then installs it in a 32-bit LBA limited enclosure.
 
#16 ·
Let me see if I can make the chain of events clearer.

I bought two of these:
Costco - Seagate Backup Plus 4TB Desktop Drive customer reviews - product reviews - read top consumer ratings
I extracted the bare drives from the enclosures (voiding the warranty).
I put them in a new enclosure, one of these (swapping them in and out as needed):
http://www.amazon.com/Rosewill-RX-358-U3C-BLK-Enclosure/dp/B005KGNXTE
This new enclosure has both eSATA and USB 3.0
I connected them to a linux server with an eSATA cable.
I wrote a GPT to both of them.
I formatted them both with a single 4TB ext4 partition.
At this point their original enclosure should be irrelevant.
I loaded data onto them.
I used them for months.

Now I come and find disk I/O errors.
Running badblocks on the drives while in the enclosure, and connected via eSATA gave me tons of I/O errors.
Currently I am running badblocks on one of the drives using the USB3.0 connector. It is 50% of the way through, and has not found any errors.

Theory: The eSATA controller is to blame. But this is something I never knew could happen.
 
#17 ·
The original Seagate enclosure would have been configured with a single 4TB MBR partition and a sector size of 4096 bytes. That would account for the complexity, although Linux should handle 4Kn drives without any trouble. But that's irrelevant now, as you say.

Are you seeing problems at random locations or do they begin at a particular sector and continue to the end of the drive?

I notice that your Amazon URL states that the enclosure contains Asmedia's ASM1453 and ASM1051 chips. The drive's SATA interface appears to be switched between the ASM1051 chip's SATA host and the external SATA host via the ASM1453 chip. Both chips are 3Gbps devices. Could it be that the drive has managed to negotiate a 6Gbps SATA link rate with the external host, and that this link rate is not being handled well by the switch? That said, the SMART report shows 5 UDMA CRC Errors, so maybe that's not the answer.

From Asmedia's web site ...

"ASM1453 is a 2-differential-channel signal switch which is used to mux/demux high speed signals. It support 1:2 or 2:1 multiplexer/demultiplexer switch with low On-Resistance, low crosstalk, operating at 1.8V supply."

ASMedia Technology Inc. ????

"ASM1051 is the single chip solution to bridge both SuperSpeed USB (USB3.0) and High Speed USB (USB2.0) to Serial ATA. It is highly integrated with ASMedia SuperSpeed USB3.0, High Speed USB2.0 and SATA1.5/3.0Gbps self-design PHYs."

ASMedia Technology Inc. 祥碩科技
 
#18 ·
An update:

So there are two drives, both exhibited the same symptoms.
I took one, put it in the eSATA/USB3.0 enclosure.
I wiped it via USB3.0, then I reformatted it and ran badblocks on it. Took 30+ hours, but it came back clean. So it's not the drive.
Then, I switched the enclosure to connecting via eSATA (same drive) and ran badblocks again. It came back clean!
So it's not the eSATA connector?
Now, I've taken that drive out, put drive 2 in the enclosure, and sure enough, when I run badblocks via eSATA I get errors.

So here I am with two drives. Both exhibited the same problem. One, after formatting, appears completely fine (badblocks ok via USB and eSATA). The other hasn't yet been touched, but in the very same enclosure as the fine drive shows I/O errors in badblocks.

What can I do to delve into this further?

BTW, here's a sample of kern.log spam:

May 2 17:44:22 cohen-htpc kernel: [ 3554.842327] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May 2 17:44:22 cohen-htpc kernel: [ 3554.842327] sd 9:0:0:0: [sdj] CDB:
May 2 17:44:22 cohen-htpc kernel: [ 3554.842328] Read(16): 88 00 00 00 00 00 00 b7 2c c8 00 00 00 08 00 00
May 2 17:44:22 cohen-htpc kernel: [ 3554.842337] sd 9:0:0:0: [sdj] Unhandled error code
May 2 17:44:22 cohen-htpc kernel: [ 3554.842338] sd 9:0:0:0: [sdj]
May 2 17:44:22 cohen-htpc kernel: [ 3554.842338] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May 2 17:44:22 cohen-htpc kernel: [ 3554.842339] sd 9:0:0:0: [sdj] CDB:
May 2 17:44:22 cohen-htpc kernel: [ 3554.842340] Read(16): 88 00 00 00 00 00 00 b7 2c d0 00 00 00 08 00 00
May 2 17:44:22 cohen-htpc kernel: [ 3554.842349] sd 9:0:0:0: [sdj] Unhandled error code
May 2 17:44:22 cohen-htpc kernel: [ 3554.842349] sd 9:0:0:0: [sdj]
May 2 17:44:22 cohen-htpc kernel: [ 3554.842350] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May 2 17:44:22 cohen-htpc kernel: [ 3554.842351] sd 9:0:0:0: [sdj] CDB:
May 2 17:44:22 cohen-htpc kernel: [ 3554.842351] Read(16): 88 00 00 00 00 00 00 b7 2c d0 00 00 00 08 00 00
May 2 17:44:22 cohen-htpc kernel: [ 3554.842360] sd 9:0:0:0: [sdj] Unhandled error code
May 2 17:44:22 cohen-htpc kernel: [ 3554.842361] sd 9:0:0:0: [sdj]
May 2 17:44:22 cohen-htpc kernel: [ 3554.842362] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May 2 17:44:22 cohen-htpc kernel: [ 3554.842362] sd 9:0:0:0: [sdj] CDB:
May 2 17:44:22 cohen-htpc kernel: [ 3554.842363] Read(16): 88 00 00 00 00 00 00 b7 2c d0 00 00 00 08 00 00
May 2 17:44:22 cohen-htpc kernel: [ 3554.842372] sd 9:0:0:0: [sdj] Unhandled error code
May 2 17:44:22 cohen-htpc kernel: [ 3554.842373] sd 9:0:0:0: [sdj]
May 2 17:44:22 cohen-htpc kernel: [ 3554.842373] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May 2 17:44:22 cohen-htpc kernel: [ 3554.842374] sd 9:0:0:0: [sdj] CDB:
May 2 17:44:22 cohen-htpc kernel: [ 3554.842374] Read(16): 88 00 00 00 00 00 00 b7 2c d0 00 00 00 08 00 00
May 2 17:44:22 cohen-htpc kernel: [ 3554.842384] sd 9:0:0:0: [sdj] Unhandled error code
May 2 17:44:22 cohen-htpc kernel: [ 3554.842385] sd 9:0:0:0: [sdj]
 
Status
Not open for further replies.
You have insufficient privileges to reply here.
Top