ST5000DM003 fail

[stef123]

Hi,

í have a problem with this HDD. It was previously installed in an external USB3.1 Case and was being unused, as it seems, for several years (Date Code from 2017). The drive had only 6 Hours(!) of running time after i got it from my nephew a few days ago. He told me that this drive already showed signs of failing when connected via USB (slow writing speeds, he assumed defect sectors).

So i took it out and attached it directly to SATA and the SMART-Status told me, apart from some weird entrys hich seem to be normal for particluar Seagate drives, that the drive is healthy. Copying files went "smooth" until i got to a point at around 150GB, where transfer to the HDD stalled. From then on i had more and more drive access problems - until recently, where even the SMART Status cannot be read out. It is recognized by the BIOS, doesnt´t sound at this point exactly what you would expect from a failing HDD (no endless seeking, stalling recoginition) and Linux gives straight at the Boot process a lot of IO errors, but, as i can tell, without Head action. Cables and so on are not the cause of this problem.

I am quite sure that my nephew didn´t drop this drive accidently, he is extreme careful at handling such things and if so, he would have told me for 100%.

Since i simply cannot accept to declare a 5TB drive, which has now a total of ten Hours Runtime (and that for suree), as "dead", I´d like to get at least access to this drive via RS232 and give it a try with the options being given. Rejecting this HDD would be, because of its age and since its an OEM-Drive, impossible.

An ordinary PL2303 USB=>TTL-Adapter is of course given, but i am not aware of the logic level of this particular HDD. Is it know if this Type of drive requires an 1.8V logic level and if yes, is there a simple solution (apart from using level shifters) to get the 5V TTL down to this voltage? I´ve read somewhere else on this site a solution via an Resistor and a few other few parts, but the schematics are no longer accessible. The PL2303 itself unfortunaly cannot be modified. DC-DC-Converters, Transistors (547/548) would be avaliable too.

Many thanks & best regards!

[stef123]

Argh - you know what? I´ve performed previously a Sanitize Operation to check out if this would run into write errors - i thought i had stopped this operation - but the drive was not finished, as i found out which SeaChest/Linux. Every time i´ve powered up the machine the drive was still performing this task and it was inaccessible by that.

So l let finish the job during the past hours - and the drive is perfectly fine again. But its quite interesting that this drive won´t stop doing this task even by powering it off (which i know now that this shouldn´t be done) and even respondinng with IO errors.

So i would say - success ! Fortunaly !

Best regards !

[stef123]

But it unfortunaly still has some weird issues.

Ubuntu with Kernel 5.10 and 5.17 => Copying files in Shell starts with a fast data rate, until the copy process goes down to 246 KB/Sec, eventually stalls (HDD GPT/NTFS-formatted ext4 doesn´t make a difference); that usually happens on a file File with around 900 MB in Size @ about nearly 600 MB transferred. Cancalling the Copy operation leds into a very slow response of the HDD, sometimes it responds again, sometimes only a complete shutdown will solve the issue. Host is a Dell 3020 with 8GB RAM and I5-4570.

Windows 7, Copying Files in shell, way slower than under Ubuntu, no problems so far.

HDD Buffer Test with Seachest_GenericTests, no Problem. Issued short Read/Write/verify LBA Tests , no problems. Smart Parameters ok. Different Connector with different Data Cabling doesn´t make a difference. Generating a Testfile on this HDD with up to 1 TB with dd and /dev/random - no problem. No Syslog entries at all.

[Lardman]

I can't follow your post but you're not just mistaking rubbish SMR performance for faults are you?

[stef123]

Wasn't here for a while, yes, SMR performance is rubbish, but that the transfer rate for several small files with around 400 MB in total, written to an already populated Area, drops down to about 3 KB/sec is the last what i would expect as "normal" - even with SMR. Even my old 1541 was on certain occasions faster than that - but still inacceptable for modern Computers. If i want such a write rate, i could instead hook up an analog quarter inch Reel to Reel Tape from the 50s to my soundcard and store my Data in that way..

In fact the drive was already idling for several hours, so any background job by the harddrive should be already finished. And i thought that those drives have at least an CMR-Area about 25 GB in Size, which has to be filled up until SMR R/W goes into action and slows down the overall operation. Here it looks like the HDD internal buffer gets filled up, and after that, the Write rate drops instantly.

You wouldn´t even get support for this drive, because it was sold in an external USB enclosure with an whopping 3.1 Interface (lmao) - without any hint or clue whats really inside; the manufacturer changes the HDD manufacturer from time to time; depending on which BS-MF offers the lowest price - no China-Fake, German manufacturer. And if you crack it open to get at least an answer for your questions, you will lost any guarantee (btw - it was out of guarantee anyways, but nearly unused with 10 Hours on the drive). And Seagate seems doesn´t support such drives at all (at least my serial Numbers gets rejected when seeking for possible Firmware updates).

If they would offer an "downgrade" Firmware resulting of having half the capacity but with full speed, i would be definitely happier. But you can count on it that this won´t happen. "Sold as is".

[labtech]

Could you run a read test with hddscan or similar software? Would like to see what the graph looks like.
I suspect the drive may have a weak/damaged head.

[stef123]

Sry for being inactive, wasn´t here.

The Graph (measured under Linux) didn´t look too suspicious to me, tested with 1 MB and even with 1 GB "Sample Size" over 1000 rounds. I don´t have the numbers currently at my hand, but the transfer rates were good. The HDD is performing again a sanitize operation, after it dropped again down do a few KB/sec, but this time with already over 300 GB written onto a BTRFS Filesystem (its been said that this is the best FS for shingled Drives). Drive Temperature is about 47 Degree Celsius. Sanitizing as also running since since 10 Hours and progress is about 7.50%, whereas it should be done (according to smartctl) in about 680 Minutes.

This is what makes me wonder. I can test what i want, Long / Short, DST Smart Test, LBA Test and so on, i never get any error reports, aside from a rather high rate in Terms of read/seek error in SMART, but as i have read, this can be quite "normal" with Seagate drives, since they seem to use a rather unusual number formatting in those fields. At least i have zero reallocated sectors after 26 Days total running Time on the drive (Heads have 13 Days). I can assure that i've changed many times cabling and SATA Ports.

Weak head, bad electronics, Firmware issue - idk. If this issue remains in the next days, i will kick the drive out.

[Tomset]

stef123,
Disk SMR!
that's how it should be

[stef123]

If SMR should be the case, it woldn´t have written over 300 GB in half an Hour and then dropping down to nothing, even being inaccessible for any other operation, for no reason. Because if SMR would generate the trouble, it would in my opinion start stalling or drop the transfer rate right after the CMR buffer area of around 25GB has been filled up.

It would never hit the market if a 5 TB Drive would drop down to a few Kb/sec or stallig after a certain time - constantly. In my case it would take literally months(!) of continuous copy operation to fill up the entire space, because it would not "recover" in any way and resumes transferring at a higher speed, even not for a single moment. It stucks at this transfer speed. As said, i am now at around 10% of Saniziting operation and we're for sure over 12 Hours now. 3 hours per TB should be called as normal.

Something is -very- wrong here.

[stef123]

After it took over one Week(!) in order to finish the sanitize Operation (Computer was running 24/7), it seems to work better.

The drive did again completely stall with NTFS at around 310GB, with BTRFS it goes over this point. Now 600 GB have been written in 1:42 Hours, and provides at least write speeds between 6 and 20 MB for Files over 1 GB in size, after it has written a fairly long time at about 160 MB/sec - thats what i am expecting in reality from SMR.

So, in conclusion - since hardware defects can be excluded, it seems to me the Firmware -or whatever else- has Problems with handling Files of different sizes in combination with NTFS. Maybe too much fiddling between CMR=>SMR Area and vice versa, meanwhile additional R/W access to the MFT, meanwhile pushing additional Data onto the drive and so on - ending up in a complete Mess of tasks; the drive is unable to handle it and goes to a "whatever mode" - at least one that makes the drive more or less unusable.

Maybe this issue couldn´t be seen in Computers, where this drive has to read more than it writes every day - but is generally unable to handle large amounts of written Data -at once- in combination with certain Filesystems. As Spock would say: That would be the most logical answer for me. Is it a Bug - idk. PersonalIy i would say yes; Seagate would probably say - no. Wrong Product usage or whatever. The question is if this problem applies to all Seagate shingled drives.

[labtech]

It does not make sense to be a firmware issue.
Firmware issues do not discriminate with regard to user data problematic area.
Something else is going on.