2

I have a new 8TB Seagate Archive disk in one of my machines (Ubuntu 14.04.2, Kernel 3.19 from git.freedesktop.org, MSI 7817, Haswell chipset, i5-4570 CPU) and there are multiple issues with this disk. See also here.

First, every now and then the disk times out and becomes completely inaccessible under large write loads (see log below). If I umount it when this happens I get a kernel oops. As long as it does work, its write performance (tested with rsync) is very irregular and jumps between 180MB/s for a second, then between 12MB/s and 40MB/s and then to several seconds doing nothing (while the disk LED is constantly lit).

On average I get about 30MB/s write performance out of this disk, which is disappointing. Read performance does not seem to suffer.

1. Is this normal? The disk has Seagates new "shingled" tracks that require rewriting adjacent tracks when changing data on one track. Update: According to answers below, the answer would be "Yes". The disk design makes write performance somewhat unpredictable if you write more than ~15GB at a time.

2: How do I avoid the crashes and SATA timeouts? I have changed cables, disk location in my PC case, cable routing in the case, used "noncq" and "acpi=off" and various other kernel parameters, none of these solved the issues completely. Even increasing the SATA timeout for this disk did not avoid the problem 100% (although it made it occur less often).

[Kernel messages, debug info and some text removed since the question was downvoted. I assume this is because it was too long. Thank you for removing the downvote. :)]

Jens
  • 139
  • 1
  • 9
  • 4
    According to this review, the drive is more or less behaving as designed: http://www.storagereview.com/seagate_archive_hdd_review_8tb TL,DR: really bad at writing a lot of data. – Don Zoomik Apr 11 '15 at 21:06
  • Thanks. In this review the disk starts write performance at >100MB/s, then goes down to a few MB/s and eventually settles at about 30MB/s. This I would accept. But my disk starts out with highly fluctuating write performance, then long pauses with no writes at all (but a filled NCQ) and eventually write timeouts and SATA bus resets. These occur even when reading from a source that isn't much faster than 30MB/s anyway (like an old USB2 HDD or a network share). So why does my disk pause completely, and not just slow down? – Jens Apr 12 '15 at 19:59
  • @DonZoomik, this makes no sense. Shingled drives can *only* do large sequential writes, at least to the areas that are shingled. It is when you try to do random overwrites that you run into problems since at least until operating systems become shingle aware, the drive has to internally erase and rewrite large tracks. I would imagine this internal drive emulation, not unlike SSDs, needs TRIM enabled to effectively manage this emulation, and without it, leads to this terrible sustained sequential write throughput since the drive has to rewrite data it must assume is still needed. – psusi Apr 13 '15 at 02:25
  • So is it possible that my disk acted like it did because I copied data from an old 1TB external USB2 disk that could only do 30MB/s? I could see the disk writing for ~1s at ~180MB/s every 5..10s, so I had assumed it would have enough time in between to do its "shing" (no pun intended). – Jens Apr 13 '15 at 19:31
  • Update: I also tried copying from a fast medium (SSD) and the symptoms are still the same. However I can find no other reports online with similar symptoms. I already upgraded to kernel 4.0.0-rc7, no change. I also had to return the harddisk three times because the first units were completely unusable (wouldn't even turn on or had lots of bad sectors), so chances are that I have again a bad disk (or found a bug in the firmware), but how do I tell? `smartmontools` tell me the disk is fine. – Jens Apr 18 '15 at 18:34
  • Have you tried [disabling/increasing the Linux hard drive timeout](http://unix.stackexchange.com/a/177767/58393), which may be set to 30 seconds? – basic6 Aug 10 '16 at 15:58

3 Answers3

3

I am having exactly this problem now, running Fedora 21. I have four of the Seagate 8TB drives (ST8000AS0002-1NA17Z, AR13). The array was built while running a 3.18 kernel and besides the performance not being the greatest, everything was working fine (and I torture tested the drives with a mix of both streaming and random writes for four solid days while the arrays were building). I then booted into the 3.19.4 kernel to test out an unrelated fix. Not long thereafter I started seeing drive "failures" (but they passed diags on my test rig). Eventually last night all four drives just dropped off the bus completely. They fortunately all came back after a reboot, I went back to 3.18.9 and everything has been stable since.

So, umm, try the last 3.18 release? Works for me. I did file https://bugzilla.redhat.com/show_bug.cgi?id=1213090 just in case.

Edit: Another 22 hours of continuous heavy load testing without issue under Fedora's 3.18.9 kernel (kernel-3.18.9-200.fc21.x86_64).

Jason Tibbitts
  • 131
  • 2
  • Thank you! I tried many kernels between 3.17 and 4.0.0rc7 and all exhibit the timeouts and subsequent crashes of the SATA subsystem with this drive in my system. I cannot go below 3.17 because of https://bugzilla.kernel.org/show_bug.cgi?id=59321. Also I actually suspect I have *another* failing drive right now (some SMART "End-to-End" errors appeared yesterday evening), so I'm slowly losing my faith in Seagate, again ... Can you try increasing the SATA timeout in 3.19 and see if the array stays alive? It's in `/sys/block/sdX/device/timeout` where `sdX` is your disk. Thanks! – Jens Apr 19 '15 at 20:25
  • 1
    Yeah, I think SMART errors would be entirely orthogonal to this. I have ordered another drive that I can use for experimentation. Also, I posted on the linux-ide list and received a reply from a Seagate engineer who is interested in my worklist. You might want to join in or at least follow the discussion. http://marc.info/?l=linux-ide&m=142956580918560&w=2. (Sorry, keep hitting enter which submits the comment instead of going to another line.) I have ordered another drive which I can use for experimentation; when it comes I'll play with the timeout. – Jason Tibbitts Apr 20 '15 at 22:14
1

I have no experience with the drive in mention but it is quite possible it's a faulty drive. A good test is remove all data that you can off of the drive and test it in a completely separate system to check performance and if issues persist than warranty it to the manufacture, if the replacement drive you receive has the same symptoms it's possible there is a bottleneck in the system or the drive is functioning as designed.

I have one of those Seagate 2TB Hybrid Drives (Has an 8GB SSD for I guess a type of hot caching). It seems to have a similar issue where in it likes to spin down the platters even after a short idle sometimes it feels like during a transfer. It can get quite frustrating transferring data and then it hiccups and has to pick it self back up because some how it slipped at the same time.

I have a decent set up

OCZ RevoDrive3 x2 240GB (C:) Seagate Hybrid Drive 2TB (D:)

So I have my Steam Library and my Windows Library folders moved and organized:

  • D:
    • Library
    • Steam
    • Backup
    • etc

Inside 'Library' are the folders managed by Windows Documents, Downloads, Music etc, But I left things like Favorites, OneDrive, Saved Games, Desktop and AppData on the SSD for maximum performance and lack of use. The issue I get is that loading games takes quite a while then the drive likes to spin down pretty much ever moment of pause it gets. As well when I click on my Documents and browse around in the folder if I switch a folder the drives already started to spin down so I have to wait for it to finish and spin back up just to change directories.

I have heard some drives got a firmware fix for this but not these model of the Hybrid Drives.

TL;DR Test in another environment and if still exist warranty it if possible, and if you do and the problems still exist then its possible it's your SATA controller or it's by design.

Zeenjayli
  • 43
  • 1
  • 8
  • Unfortunately I have no other environment to test in right now (just two identical PCs). But I already had three of those drives: the first had a thousand bad sectors (according to SMART) after a couple days, the second wouldn't even spin up and the third now has those timeouts and "End-to-End" errors. I'm starting to feel a little stupid, other poeple are totally happy with the drives according to some reviews in online shops ... – Jens Apr 19 '15 at 20:31
0

During part of my carrier I worked for a large corporation and we worked with Seagate directly on many occasions...

...Seagate has a vested interest in resolving this. Posting here is BAD publicity for them. You can be SURE to get their full and undivided attention, AND, likely, help enough you can post something back here for us about the experience.

I STRONGLY encourage you to contact Seagate directly. I BET you'll get a lot of help!

Richard T
  • 1,206
  • 12
  • 29
  • I tried when I got the first disk which failed (see https://bugzilla.kernel.org/show_bug.cgi?id=93581). Seagate phone support pointed me to where I bought the drive. They also said getting it replaced there would be better for me because if I talked to Seagate directly I would get a refurbished drive as a replacement and it would take longer ... – Jens Apr 19 '15 at 20:29
  • 1
    "Customer support" isn't likely to give you the help needed for this. Escalate the call! – Richard T Apr 21 '15 at 02:36
  • 2
    That's true. Here's what Seagate Support has to say about SMART errors and SATA timeouts: "Thank you for contacting Seagate Support. I do apologize for the inconvenience. Unfortunately, It appears that you are not using the hard drive for what it was designed for. This would explain the data loss, and the issues you are experiencing. ..." Of course! Disk errors are always the user's fault. Aren't they? – Jens Apr 22 '15 at 21:21
  • 2
    OTOH, Seagate actually works on host aware SMR disks and has already started optimizing Linux file systems, I/O layers and so forth to exploit the performance potentials of such disks. See here: https://github.com/Seagate/SMR_FS-EXT4 and here: http://article.gmane.org/gmane.linux.ide/59715 Which sounds VERY promising. – Jens Apr 22 '15 at 21:24