dslreports logo
 
    All Forums Hot Topics Gallery
spc

spacer

Search Topic:
uniqs
1092
share rss forum feed

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable

[hard drive] Anyone know what SMART ID 234 is?

I just got a brand spankin' new 240 GB Seagate 600 SSD.

Right off the bat I was seeing something that was worrying me - "uncorrectable ECC count" was reporting "160 sectors". It's rising continuously, it's been two days and it's now reporting 777.

However this is reported by Linux's "disks" program. smartctl reports:

...
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
...
194 Temperature_Celsius 0x0022 036 000 000 Old_age Always - 36 (Min/Max 21/57)
201 Unknown_SSD_Attribute 0x0032 100 100 000 Old_age Always - 0
204 Soft_ECC_Correction 0x0032 100 100 000 Old_age Always - 0
231 Temperature_Celsius 0x0013 100 100 010 Pre-fail Always - 0
234 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 777
241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 351
242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 108
250 Read_Error_Retry_Rate 0x0032 100 100 000 Old_age Always - 0
...

It doesn't actually know what ID 234 is. Looking around I see that for SandForce drives (yes this is not a SandForce drive):

»superuser.com/questions/475635/w ··· internal

it's "SandForce_Internal" which tracks host writes vs. NAND writes. It's actually ID 195 that tracks uncorrectable ECC errors, at least on SandForce drives:

»www.ocztechnologyforum.com/forum ··· t-series

Of course neither program tracks ID 195.

I'm hoping this is just a mix-up as to what ID 234 actually is. The Seagate 600 is quite new, most likely neither program has seen it before. The fact that it's constantly increasing may mean that it's tracking writes of some sort. It looks like manufacturers follow SMART ID numbering conventions rather loosely and may assign certain ID numbers to something only they can interpret.

At least that's what I'm hoping.

Any ideas?

germanbuick

join:2001-12-16
Reno, NV
If its a new drive, the Mfr. is going to want to know the results of their test app. run on the drive, for warranty?But I only see Seatools for Win OS's,maybe there's another tester that is 'nix based?? dunno know...load it with WIN Xp/7/8? and run seatools? dunno know...


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to Fraoch
You intentionally chose to omit full output from smartctl -a -- why I do not know. The fact you omitted this isn't cool. Please provide full output; once you show everything, I can almost certainly tell you what's going on. You can XXX out the drive serial number if you want, but please do not edit anything else.

And if you can also provide output from smartctl -x I would appreciate that as well.

P.S. -- Reminder (or informative if you're unaware): SMART attributes -- both what ID number maps to what capability/feature, and the the encodings of the 6-byte RAW_VALUE field -- are not defined per any T13 ATA standard. Welcome to the nature of the beast that is SMART -- send all complaints to T13.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
reply to germanbuick
said by germanbuick:

If its a new drive, the Mfr. is going to want to know the results of their test app. run on the drive, for warranty?But I only see Seatools for Win OS's,maybe there's another tester that is 'nix based?? dunno know...load it with WIN Xp/7/8? and run seatools? dunno know...

They have a FreeDOS version which would run on any system at boot. I may try that.

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
reply to koitsu
said by koitsu:

You intentionally chose to omit full output from smartctl -a -- why I do not know. The fact you omitted this isn't cool.

I omitted it for brevity and because the rest of it didn't seem relevant.

Full output:


I notice attribute 234 is up to 945 now.

And if you can also provide output from smartctl -x I would appreciate that as well.

Sure, thank you:


(whew)

Attribute 234 rose by 1 between the time I issued the first smartctl command and the second...

I also see it's logged 24 errors in its short lifetime - I'm hoping this is typical, just not something the end user usually sees.

P.S. -- Reminder (or informative if you're unaware): SMART attributes -- both what ID number maps to what capability/feature, and the the encodings of the 6-byte RAW_VALUE field -- are not defined per any T13 ATA standard. Welcome to the nature of the beast that is SMART -- send all complaints to T13.

I have read your posts on this subject and I'm hoping that's the case here as "Disks" and smartctl differ on what this attribute actually is. I hope it's just Seagate's own special attribute for something - I notice the next two attributes track total writes and reads, I hope it's somehow connected to those two.

Thank you!


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
1. This line:


Is the most definitive there is. It indicates that the drivedb.h that smartmontools uses does not have support for the drive in question. update-smart-drivedb should download the latest, but I make no guarantees they've added support for it since 6.2.

You therefore need to post on the official smartmontools mailing list (or over on sourceforge) asking for help. Be sure to point out the fact that attribute 234 is unknown as of this writing.

It also looks to me like attributes 241 and 242 are also decoded wrong -- those counters do not indicate the number of literal LBAs read/written, but almost certainly indicate the number of 32MBytes read/written during the drive's lifetime. How do I know this? This is pretty standard behaviour on SSDs; the best example there is comes from Intel drives, where attributes 241 and 242 are decoded that way. Intel also documents their SMART attributes publicly (in their User Guide). So it's very likely Seagate implemented the same methodology using the same attribute numbers. You need to point this erroneous decoding out to the smartmontools folks, so they can properly update drivedb.h to refer to them as Host_Writes_32MiB and Host_Reads_32MiB.

I believe some of the maintainers have some sort of relationship with drive companies to get information about certain attributes. So you will need to work it out with them. If Seagate never discloses publicly what the attribute is, then there is nothing you or anyone else can do about it. Sad but true. :-(

2. The 24 errors in your SMART error log are harmless. The ATA CDB log clearly shows that the errors are induced by something within the ATA driver or operating system (often induced by certain tools/utilities) attempting to enable certain APM functionality/capability, which this model of drive rejects cleanly (ABRT status). These are classified by Seagate as "error conditions", and that's entirely their choice. Their response would be: "the OS/driver/utility should not be submitting APM adjustment commands on this model of SSD".

If you want me to decode one of the error log entries (they're all mostly the same) and write it in English, I can, but it's this simple: READ FPDMA QUEUED is a read I/O request using NCQ, and these were not the cause of the error. In one case the next CDB was ATA IDENTIFY, which discloses capabilities of the drive itself. The CDB which induced ABRT status was SET FEATURES, specifically the sub-command to enable APM.

My guess is libata is doing this during system power-on (you can determine that by cleanly rebooting (shutdown -r now) the system and seeing if the error log entries increase). If so, you need to report this anomaly to the libata/Linux kernel maintainers and inform them that your model of SSD does not support adjusting APM parameters. Show them the lines and they should understand.

There is no anomaly happening here per se, other than the kernel or libata may need a "quirk entry" to exclude trying to set APM capabilities on that particular model of drive. This sort of thing is required all the time for disks (SSDs and MHDDs alike), so it's nothing new.

3. Do not make any assumptions about what the attribute means by "where" its located within the attribute list. The location nor its number have any relevancy to other attributes surrounding it.

4. Probably the most important thing of all: your drive looks totally healthy to me. There is no sign of any problems with your disk given what smartmontools knows of it (but it's not in the drivedb), but like you I too would be curious to find out what attribute 234 really counts/represents.

If you don't get any answers from the smartmontools folks, then it's up to you to contact Seagate Technical Support and ask them to give you details. They will need to contact their engineering dept. internal to Seagate and provide you with the description of the attribute. You can then give that to the smartmontools folks and they should be able to add the necessary code/bits into the drivedb.

Sorry I can't be of more assistance, but welcome to the world of SMART and the lack of standardisation by T13. This is the world we have to deal with.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
said by koitsu:

You therefore need to post on the official smartmontools mailing list (or over on sourceforge) asking for help. Be sure to point out the fact that attribute 234 is unknown as of this writing.

It also looks to me like attributes 241 and 242 are also decoded wrong -- those counters do not indicate the number of literal LBAs read/written, but almost certainly indicate the number of 32MBytes read/written during the drive's lifetime. How do I know this? This is pretty standard behaviour on SSDs; the best example there is comes from Intel drives, where attributes 241 and 242 are decoded that way. Intel also documents their SMART attributes publicly (in their User Guide). So it's very likely Seagate implemented the same methodology using the same attribute numbers. You need to point this erroneous decoding out to the smartmontools folks, so they can properly update drivedb.h to refer to them as Host_Writes_32MiB and Host_Reads_32MiB.

Although I couldn't update ("/var/lib/smartmontools/drivedb/drivedb.h.error: rejected by /usr/sbin/smartctl, probably no longer compatible" - strange since it's the latest release) I checked the database and it's not in it, not surprisingly. I requested they add it to the database.

I believe some of the maintainers have some sort of relationship with drive companies to get information about certain attributes. So you will need to work it out with them. If Seagate never discloses publicly what the attribute is, then there is nothing you or anyone else can do about it. Sad but true. :-(

Running Linux, I'm used to manufacturers not cooperating.

2. The 24 errors in your SMART error log are harmless.

Aha. Thank you!

My guess is libata is doing this during system power-on (you can determine that by cleanly rebooting (shutdown -r now) the system and seeing if the error log entries increase). If so, you need to report this anomaly to the libata/Linux kernel maintainers and inform them that your model of SSD does not support adjusting APM parameters. Show them the lines and they should understand.

There is no anomaly happening here per se, other than the kernel or libata may need a "quirk entry" to exclude trying to set APM capabilities on that particular model of drive. This sort of thing is required all the time for disks (SSDs and MHDDs alike), so it's nothing new.

I haven't done this yet as it's a bit more involved but I'll be working on this.

4. Probably the most important thing of all: your drive looks totally healthy to me.

Excellent, thank you. I thought so - I just installed a new OS on it (Linux Mint 16) and transferred over all my data, so if it was failing in any way I should have seen something. But it's been running flawlessly.

Thanks again for your assessment.

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
reply to Fraoch
Incidentally I ran SeaTools for FreeDOS by following these instructions using a Windows laptop:

»samehfakoua.blogspot.ca/2011/04/ ··· usb.html

All tests run fine but it indicates the drive has been subject to an overtemperature condition, "at or above 71 C" and gives me the option to abort all tests due to this.

I find this very hard to believe. The drive is mounted under the motherboard plate as is usual for many new cases. There are no heat-producing elements on that side of the plate. The drive temperature is currently at 35 C. smartmontools indicates the maximum it ever saw was 57. I guess SeaTools knows the drive better than smartmontools, but still, my processor has never even reached 71C+. I really don't see how the drive could ever have gotten that hot.

I sure hope Seagate doesn't use this data to deny warranty coverage. I have not abused this drive by subjecting it to high temperatures, but that's not what their tool will tell them.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 edit
reply to Fraoch
DO NOT use SeaTools on your SSD. I repeat: DO NOT USE SEATOOLS ON YOUR SSD.

SeaTools is intended for MHDDs, particularly older ones (as in 8-9 years ago), and Seagate (as do many other companies) does a horrible job of keeping it updated. It does not surprise me that the utility acts wonky with newer drives, especially SSDs.

The reason for the Min/Max temperature reading could be:

1. The drive was subject to temperature stress tests during quality assurance prior to being packaged + sold. FWIW, this is the most likely explanation. As I have stated time and time again, SMART attributes are not always reset/zeroed when a drive comes out of the factory.

2. Improper decoding. smartmontools is one utility which has the ability to decode some of the vendor-encoded 6-byte values stored in RAW_VALUE, but this methodology does not necessarily work on all drives (its entirely up to the firmware engineers to decide what the format of those 6 bytes are). So it may be that Seagate changed the encoding format and that it never reached 57C, but in fact reached something less than that and is just being decoded wrong by smartmontools. I'm doubting this, however, because I'd expect to see crazy/insane values for Min and Max, not just Max.

So as I said, #1 has my vote.

The best advice I can give about drives is that you have to learn how each individual drive model behaves, and what to expect as the norm, when reading SMART statistics. You cannot read them or treat them the same way universally across all drives. The way I phrase this to people (often on this forum) is "you need to turn off your OCD when it comes to hard disks today, unless you have the experience to know and properly analyse the data that you're being shown". I say that respectfully, not judgementally.

Mister_E

join:2004-04-02
Etobicoke, ON
Reviews:
·Bell Sympatico

1 recommendation

said by koitsu:

DO NOT use SeaTools on your SSD. I repeat: DO NOT USE SEATOOLS ON YOUR SSD.

Just to provide an update - there is a version 1.2.0.10-RC (Release Candidate?) of "Seatools for Windows" that states: "Engineering Preview: SeaTools for Windows next release adds new SSD usage language and fixes SAS DST." (I know, doesn't help with your Linux set up, but thought I'd mention it anyhow). You can get this version through the Seagate Support Download Finder after inputting the relevant info.

I picked up this 240GB Seagate 600 SSD as well on Cyber Monday as NCIX had it on sale for $135 CAD. This version of Seatools for Windows does detect the drive correctly.

FWIW, Wikipedia lists:

234 0xEA
Average erase count AND Maximum Erase Count
Decoded as: byte 0-1-2 = average erase count (big endian) and byte 3-4-5 = max erase count (big endian)

Interesting thread, thanks for the info koitsu See Profile!

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
reply to koitsu
said by koitsu:

DO NOT use SeaTools on your SSD. I repeat: DO NOT USE SEATOOLS ON YOUR SSD.

SeaTools is intended for MHDDs, particularly older ones (as in 8-9 years ago), and Seagate (as do many other companies) does a horrible job of keeping it updated. It does not surprise me that the utility acts wonky with newer drives, especially SSDs.

I thought: "who would better know my SSD than the manufacturer"? When you have any inquiry about the 600 at the Seagate website, they always recommend SeaTools. Seems to be just a generic support response then.

The way I phrase this to people (often on this forum) is "you need to turn off your OCD when it comes to hard disks today, unless you have the experience to know and properly analyse the data that you're being shown". I say that respectfully, not judgementally.

No problem. I'll stop obsessing about it now.

Fraoch

join:2003-08-01
Cambridge, ON
kudos:2
Reviews:
·TekSavvy Cable
reply to Mister_E
said by Mister_E:

Just to provide an update - there is a version 1.2.0.10-RC (Release Candidate?) of "Seatools for Windows" that states: "Engineering Preview: SeaTools for Windows next release adds new SSD usage language and fixes SAS DST." (I know, doesn't help with your Linux set up, but thought I'd mention it anyhow). You can get this version through the Seagate Support Download Finder after inputting the relevant info.

Ah, I hadn't found that link. (Seagate's website is hard to navigate.) Very useful. I see the RC, which incidentally has been in RC status since October 9th, and I see SeaTools-FreeDOS remains at 2.23 which hasn't been updated since February 9th, 2011.

I see the area where a firmware upgrade would be offered if there was one (there isn't).

I also see the 600 is code-named "Wolf".

I picked up this 240GB Seagate 600 SSD as well on Cyber Monday as NCIX had it on sale for $135 CAD.

Heh heh I got it from the same place - I got it for $5 more than you did early Black Friday, then it went out of stock, then it went back up at a higher price, then it was at $135 on Cyber Monday, but not for long.

FWIW, Wikipedia lists:

234 0xEA
Average erase count AND Maximum Erase Count
Decoded as: byte 0-1-2 = average erase count (big endian) and byte 3-4-5 = max erase count (big endian)

Well now that makes much more sense, given that it's risen to 1156 this morning. And even that's not a valid number, given that it should be decoded as 2 parameters based on the bits. What's yours reading?

Thanks for the info.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
said by Fraoch:

FWIW, Wikipedia lists:

234 0xEA
Average erase count AND Maximum Erase Count
Decoded as: byte 0-1-2 = average erase count (big endian) and byte 3-4-5 = max erase count (big endian)

Well now that makes much more sense, given that it's risen to 1156 this morning. And even that's not a valid number, given that it should be decoded as 2 parameters based on the bits. What's yours reading?

If you want to reverse-engineer this, you can use smartctl -H -r ataioctl,2 /dev/sda to dump the full payload data. The ATA command for SMART attribute retrieval is 0xb0 ("SMART READ DATA" / "SMART READ ATTRIBUTE VALUES"), feature request 0xd0. The hexadecimal data you get back are all the attributes and their values. For the format of most (but not all) of the data, you will need to read the smartmontools source code. Taken from my own code comments:


The 6 bytes of Attribute data, stored in big endian format (i.e. linear order), are what make up the results. Bit-level decoding is not involved here; you simply split the 6 bytes up into halves (3 bytes each).

I'm going to take an educated guess and say that attribute data returned for that attribute on your machine is 00 00 00 00 00 04 84 (1156 in decimal).

I would interpret this as "max erase count 1156, average erase count 0", and that is making the blind assumption that what Wikipedia has applies to your model of drive (it very well may not -- possibly it indicates the number of times the drive has issued an internal NAND erase page request -- again this is me speculating, there is no evidence of such).

Let the smartmontools folks figure it out. You can give them output from the above command, by the way, as it will certainly help them.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.

Mister_E

join:2004-04-02
Etobicoke, ON
Reviews:
·Bell Sympatico
reply to Fraoch
said by Fraoch:

Well now that makes much more sense, given that it's risen to 1156 this morning. And even that's not a valid number, given that it should be decoded as 2 parameters based on the bits. What's yours reading?

Mine pulls up a RAW value of 000000000744.