10

My Seagate Momentus XT hybrid hard drive is corrupting files on Linux. I would appreciate help from anyone, but I'd particularly like to know if other Momentus XT users are able to reproduce this problem; I have provided step-by-step instructions for reproducing this issue on the Seagate Community Forums.

So far, four users have reproduced this problem on the following laptops and OS/distributions:

  • Five laptops: Lenovo Thinkpad T60, T61, T510, MSI MS-1656-ID1, and MacBook Pro (15" late 2009).
  • Four OS/distributions: Ubuntu 11.04, Fedora 15, openSUSE, and Mac OS X.

The instructions for reproducing the problem are simple. Here is a brief verbal description:

  1. Create a large test file, save it to another storage device (not the Momentus XT), and compute the SHA-1 checksum.
  2. Write the test file to the Momentus XT.
  3. Read the test file from the Momentus XT, calculate the SHA-1, and compare this checksum with the checksum of the original. We should have a match. We have probably reproduced the problem if they don't match. (Only 'probably', because it is possible for other issues to cause a mismatch. See the Seagate thread about identifying this specific problem by comparing the files with cmp -l.)
  4. Repeat from step (2).

The Seagate thread has more details. Here are some notes from my testing (I have been able to reproduce this problem on three consecutive Momentus XT drives; I RMA'd twice and am now on the third one):

  • What seems to be happening is that the Momentus XT sometimes neglects to write data to the drive, so that when I read from the drive, I get what was originally on the sector, and not the correct data. This occurs in blocks of different sizes; typical sizes are 1 MiB and 512 KiB.
  • Problem occurs on ext2, ext4, Btrfs, NTFS, and FAT32. Strangely, I was not able to reproduce this problem on ext3.
  • Writing with the oflag=direct output flag in dd avoids this problem. Rapidly commiting data to disk with while true; do sync; sleep 0.01; done also prevents the problem.
  • I have only been able to reproduce this problem through a SATA and an eSATA interface. A USB connection seems to prevent the problem. (Not sure if this is due to transfer speed.)
  • Problems occur more often with large files (>2 GB). I was not able to produce problems with files smaller than about 85 MB.
  • I was not able to reproduce the problem on Windows XP with NTFS.
  • Gazoi at the Seagate forums was unable to reproduce the problem on FreeBSD 8.2 with UFS2.
  • The Momentus XT passes both the extended SMART test and badblocks -w with no issues.
  • My laptop (MS-1656-ID1) has successfully passed through 24 hours each of Memtest86+, Memtest86, memtester, and MPrime.
  • I have tested two other storage devices (a Seagate Momentus 7200.4 and an Intel 320 series SSD) with the same procedure, and they both pass with no issues.

If you have a Momentus XT, please try reproducing this problem and let me know what happens.

What else can I do to diagnose the problem?

Improve this question
22
  • 1
    Are you rebooting between the write and the read? Are you flushing the cache to make sure that it is actually read back from the disk instead of cache? If not, that may be why you can't reproduce it with smaller files since they are more likely to still be in the cache
    – psusi
    Jul 19, 2011 at 19:29
  • I am bypassing the page cache by reading with the iflag=direct input flag with dd. When I am not using dd, I flush the cache with sudo sh -c "sync && echo 1 > /proc/sys/vm/drop_caches"
    – Ironclaw
    Jul 19, 2011 at 20:22
  • I just realized that you might be talking about the disk buffer that is physically on the Momentus XT, instead of the Linux page cache. You have a point in this case - I am mostly not taking any precautions against reading the disk buffer, and I am also immediately reading the file after writing it. Perhaps I should commit writes to multiple files, and then read them on a FIFO basis. With that said, the Momentus XT disk cache is only 32 MB, and I have also done some tests in the past where I have wrote >10 GB of small files (~64 MB), and read them afterwards without any finding corruption.
    – Ironclaw
    Jul 19, 2011 at 20:40
  • Maybe there's a bug in the drive's firmware (integer overflow?) that causes it to loose track of unwritten blocks under high speed write. Or there are some bad blocks on the flash that the firmware failed to detect. NTFS verifies writes (and ntfs-3g is very slow), so the problem is unlikely to appear. If you can't find a fix, you may want to use ZFS and enable checksum.
    – billc.cn
    Jul 21, 2011 at 21:08
  • @billc.cn, I have reproduced the problem with NTFS. Btrfs and ZFS with data checksums will conspicuously fail to read corrupted files, but the corrupted data will be unrecoverable. More redundancy (e.g., FS-level mirroring or RAID mirroring) will be needed to recover these files. In any case, I am of course not using the Momentus XT until I figure out what's happening.
    – Vincent Yu
    Jul 21, 2011 at 21:24

3 Answers 3

Reset to default
6

Updating the firmware to SD26 fixes this problem with file corruption on Linux. Unfortunately, SD26 has not been publicly released.

The best way to obtain the SD26 firmware is to ask Seagate for a copy of the bootable update CD or Windows update utility.

I emailed Seagate Technical Support on August 20 to ask about SD26, after I discovered that it solved my problem with file corruption. Here are the two replies that I received from Seagate Global Customer Support on August 23:

Thank you for contacting Seagate today. Give me some time to get with the developers so I can see what is going on with the SD26 firmware. Because of your discoveries we need to do a little investigating. We do very little testing with Linux. Let me see what I can find out and if further testing and a public release of the firmware is needed. I am attaching the ISO file. I will be getting back with you as soon as I hear back. Seagate is very customer oriented and we appreciate you bringing this to our attention.

We usually do not make firmware available publicly. It can do more damage then good in the wrong hands. We receive a lot of bricked drives from improper updates.We like for consumers to contact us, so that we can verify that a firmware upgrade is needed and beneficial. Alan M. is our moderator for the forums and he will be making an announcement on your thread. Again, thank you for bringing this to our attention. Our customers are the best, and a great source of information and usually the first to let us know when things are not working as they should. Allow us the chance to fix the problem.

As I have stated already, I think it is best to get SD26 directly from Seagate. However, there are also leaked copies of both the bootable ISO and the Windows utility that are easily found by searching on Google. The SHA-1 checksum of the SD26 bootable update CD (*.iso) that I received from Seagate is b7b0c7e1b9529925b0364b2cf19a62d608b58082.

I have posted the information in this answer, and other miscellaneous details, in the Seagate thread.

Improve this answer
1
4

All mention of this problem have been removed from the Seagate forums. They probably figure that the discussion is unnecessary now that one can fix the problem by updating to SD28.

The only problem with that is that people no longer have a means to get authoritative info describing the problem, and/or how to fix it, since all references to any correlation between the problem and it's solution have been removed from the Seagate site. The firmware update download is still available, but there is no mention of what the firmware does, so affected users may have difficulty trying to find a solution.

So to help googlers: The SD28 firmware download at http://knowledge.seagate.com/articles/en_US/FAQ/215451en?language=en_US IS a solution to the data corruption bug that occurs with these Seagate Momentus XT drive models:

  • ST92505610AS

  • ST93205620AS

  • ST95005620AS

Improve this answer
2

I have just verified that is happening in OS X as well. :o(

I had suspected data corruption for two reasons:

1) the momentus XT is designed to cache frequently used files in the 4GB of flash RAM, and these files most often are small files needed to load programs during boot up (setting files, etc). With increasing frequency, my programs that are configured to load at login would suddenly come up with default settings, or give me the 'welcome tutorial' and have no settings programmed. These included mail.app (no account info stored), little snitch (port monitor with no rules), quicksilver (welcome), and others. This lead me to believe that small files in the cache are corrupted.

2) The drive suffered from causing 'spinning pinwheels' where the drive seemed to have spun down, and when the OS needed to access it I had to wait for the drive to spin up again. The waiting became more frequent and lasted longer. On several occasions I would simply wipe the drive and use carbon copy cloner to copy over everything which as previously backed up. However, after copying the files to the momentus xt many of the larger files (movies, ISO images, zip files) were corrupt, and either would not load or open. I thought the problem with the beach balls and spin-downs would be resolved when I upgraded from Snow Leopard to Lion, as a few users have posted recently about, but the 3.46Gb Dev preview ISO file I copied to momentus XT off a USB drive was corrupted so I couldn't even install Lion.

I had just stumbled across your thread at the seagate forums and come here to post:

I used a program called 'smart utility' under os x, which said that the drive was failing. I think the error was for code 184, which were "end-to-end" errors. I was alarmed that the drive was "failing" but I read that others were receiving this error when they upgraded their firmware (as I did from SD23 to SD25), and that Seagate would only deem a drive as failing if it failed under their SeaTools.

I put my momentus xt in a usb enclosure and ran SeaTools on the drive through windows on another computer. SMART Check was not an allowed test. Running 'short drive test' and 'long generic test' no errors were reported? Now I've tried to duplicate your methods under OS X, and I too found the files are getting corrupted. I'm using a late 2009 Macbook Pro 15", and I have a 500GB Momentus XT on SD25.

Fred

Improve this answer
1
  • Thanks for reporting this! Can you run the following command to compare an uncorrupted file with its corrupted copy? cmp -l <uncorrupted file> <corrupted copy> | head If we are having the same problem, you should see three columns of numbers, and the leftmost column should have ten consecutive numbers. (Details: Leftmost column shows the byte numbers of the differing bytes, and the other two columns show the actual values of the differing bytes.)
    – Vincent Yu
    Jul 26, 2011 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.