Seagate Barracuda 7200.11 Troubles

[AlexLilic]

The problem only arises if a power cycle initialization occurs when the Event Log is at 320 or some multiple of 256 thereafter.

I don't know what the Event Log that is referred to above stores, or at what rate it can be expected to increment in a "normal" scenario - but I guess we have 2 end points:

• Best case: It turns out that this Event Log is normally empty, and only used to log uncommon physical errors.
  
• Worst case: It turns out that this Event Log is commonly used, and the increment rate is closely coupled to the user's power cycle behavior. For example the drive logs on average 1 error entry per day, and the user happens to power cycle each evening. In this scenario failure rate is 100% !!
  

Anyone have any thoughts on this log file behavior? (I have of course ignored the part about only drives manufactured using a "specific test process" which limits the enture discussion to an undisclosed number of units).

P.S.

I also logged a case with Seagate Technical Support on the web regarding my 7200.11 SD15 No-BIOS detect, and the incident was closed 2 weeks later WITHOUT any email or any update. Needless to say I am Pi**sed Off. I called them just now, but their tech-support recorded message says that they are "closed due to extreme weather conditions".

I also tried pressing the automated routing choice for Segater Recovery Services but I ended up at another company who explained to me politely that SDS have left that building, but have not updated their voice system.

I can't think of a more frustrating experience that I have had with a vendor.

Edited January 27, 2009 by AlexLilic

[mikesw]

The problem only arises if a power cycle initialization occurs when the Event Log is at 320 or some multiple of 256 thereafter.

I don't know what the Event Log that is referred to above stores, or at what rate it can be expected to increment in a "normal" scenario - but I guess we have 2 end points:

• Best case: It turns out that this Event Log is normally empty, and only used to log uncommon physical errors.
  
• Worst case: It turns out that this Event Log is commonly used, and the increment rate is closely coupled to the user's power cycle behavior. For example the drive logs on average 1 error entry per day, and the user happens to power cycle each evening. In this scenario failure rate is 100% !!
  

I can't think of a more frustrating experience that I have had with a vendor.

Well, if the length of the internal disk drive log is 320 and we are recording one event per day, and I bought the drive

jan 1,2009, then in 320 days it will fail on the 321'th day. This puts it around the 3rd week of November 2009. Hmm,

now I see a correlation here between the problems people had in FY 2008 when things started dying in oct thru early december.....

Edited January 27, 2009 by mikesw

[DerSnoezie]

Anything between 20,000 and 200,000 appears "reasonable".

Even taking the lowest of the "range", 20,000 is several times bigger than the initially assumed 800.

Is it one of those days where my understanding of English is failing AND my math skills lack any kind of precision?

jaclaz

The quite reasonable numbers you mentioned above certainly do not look like a "purple squirrel" to me. Thanks jaclaz!

Edited January 27, 2009 by DerSnoezie

[Gradius2]

"We will respond, promptly, to your email request with appropriate instructions."

Big laugh at that !

I never got an answer from them, except that "automated" one.

now:

0,002*100,000,000=200,000

OK, figures above may be exagerated/wrong, let's introduce a 10 times "safety factor":

200,000/10= 20,000

Anything between 20,000 and 200,000 appears "reasonable".

Even taking the lowest of the "range", 20,000 is several times bigger than the initially assumed 800.

Is it one of those days where my understanding of English is failing AND my math skills lack any kind of precision?

jaclaz

To me was 50%. 2 out of 4 failed on same day.

They make ~10 millions HDD per month, the problem started around June until January 11. In other words, 7 months !

10mil x 7 = 70 millions HDDs, lets say the half them are 7200.11, so we have 35 millions, if we keeps 50% defective (another half) = 17,5 millions.

Now, let's estimate just 10% of 17,5 millions are unlucky and will have this problem so we have 1,75 millions HDDs, in other words, almost 2 millions worldwide I might said.

20,000 is too optimist in my opinion. This problem just wasn't bigger, because that "320 thing" is based by "luck".

[DerSnoezie]

Now, let's estimate just 10% of 17,5 millions are unlucky and will have this problem so we have 1,75 millions HDDs, in other words, almost 2 millions worldwide I might said.

LOL, that's actually a pretty fat squirrel But i guess we'll never receive any feedback on the true numbers.

[mikesw]

Today Western Digital is announcing their WD20WEADS drive, otherwise known as the WD Caviar Green 2.0TB. With 32MB of onboard cache and special power management algorithms that balance spindle speed and transfer rates, the WD Caviar Green 2TB not only breaks the 2 terabyte barrier but also offers offers an extremely low-power profile in its standard 3.5" SATA footprint. Early testing shows it keeps pace with similar capacity drives from Seagate and Samsung."

http://hothardware.com/News/WD-2TB-Caviar-...-Drive-Preview/

MSRP for the new ginormous Caviar is set at $299. You can catch the official press release from WD. Stay tuned for the full HH monty with WD's new big-bad Caviar, coming soon. http://wdc.com/en/company/releases/PressRe...3-F872D0E6C335}

spec sheet: http://wdc.com/en/products/Products.asp?DriveID=576

Warranty policy in various countries for WDC drives (2TB not listed yet) http://support.wdc.com/warranty/policy.asp#policy

buy.com has it for $272.00 http://www.pricegrabber.com/wd20eads/produ...20EADS/st=query

Edited January 27, 2009 by mikesw

[DrDisk]

Well I guess Mr. SanTools, AKA Storagesecrets was just trying to do some PR for Seagate and at the same time gave his website and company a black eye.

Looks like Seagates entire product line except the SAS drives were affected by atleast this 1 bug, but how many others suffer from other bugs.

1.5TB Studder Issue and the Log issue

1TB/500GB and other LBA 0 bug.

It's too much to keep count. Sure there are some people fanning the flames, but almost EVERY SINGLE forum has people complaining, and I'm pretty sure it isn't the SAME people at all groups. You know you have a problem with your hard drive, when the Under Water Basket Weaving forums start to have posts talking about the failures.

I hope Seagate payed Dlethe well for his PR Spin. Odd it was just 1 day before the WD announcement. Coincident?

[anonymous]

Regarding "320", here's an exchange with Maxtorman from the Slashdot forum:

Maxtorman's explanation (which was apparently correct):

I'll answer your questions to the best of my ability, and as honestly as I can! I'm no statistician, but the 'drive becoming inaccessable at boot-up' is pretty much a very slim chance - but when you have 10 million drives in the field, it does happen. The conditions have to be just right - you have to reboot just after the drive writes the 320th log file to the firmware space of the drive. this is a log file that's written only occasionally, usually when there are bad sectors, missed writes, etc... might happen every few days on a computer in a non-RAID home use situation.. and if that log file is written even one time after the magic #320, it rolls over the oldest file kept on the drive and there's no issue. It'll only stop responding IF the drive is powered up with log file #320 being the latest one written... a perfect storm situation. IF this is the case, then Seagate is trying to put in place a procedure where you can simply ship them the drive, they hook it up to a serial controller, and re-flashed with the fixed firmware. That's all it takes to restore the drive to operation! As for buying new drives, that's up to you. None of the CC firmware drives were affected - only the SD firmware drives. I'd wait until later in the week, maybe next week, until they have a known working and properly proven firmware update. If you were to have flashed the drives with the 'bad' firmware - it would disable any read/write functions to the drive, but the drive would still be accessible in BIOS and a very good chance that flashing it back to a previous SD firmware (or up to the yet to be released proven firmware) would make it all better. Oh, and RAID0 scares me by it's very nature... not an 'if' but 'when' the RAID 0 craps out and all data is lost - but I'm a bit jaded from too much tech support!

My question:

Maxtorman, is the log file written after each power-up (or POR) and before each shut down? It seems to me the #320 is being reached by many users in about 100 days... can that really be from only occasional events like bad sectors and missed writes? See this time histogram:

http://www.msfn.org/board/index.php?showto...st&p=826575

Maxtorman's response:

The log, if my information is correct, is written each time a SMART check is done. This will always happen on drive init, but can also happen at regularly scheduled events during normal usage, as the drive has to go through various maintenance functions to keep it calibrated and working properly.

_______________________

Dlethe said, "The problem is a purple squirrel (sorry about the yankee slang -- it means incredibly rare)."

Well, not if you turn your computer off every night, with or without a SMART check, at least in my opinion.

[Gradius2]

Now, let's estimate just 10% of 17,5 millions are unlucky and will have this problem so we have 1,75 millions HDDs, in other words, almost 2 millions worldwide I might said.

LOL, that's actually a pretty fat squirrel But i guess we'll never receive any feedback on the true numbers.

I would estimate at least 1/3 of them will not bother at all and will just return the drives and getting replaced by another brand at first opportunity.

Those will never post a thing or do a research about the problem.

Today Western Digital is announcing their WD20WEADS drive, otherwise known as the WD Caviar Green 2.0TB. With 32MB of onboard cache and special power management algorithms that balance spindle speed and transfer rates, the WD Caviar Green 2TB not only breaks the 2 terabyte barrier but also offers offers an extremely low-power profile in its standard 3.5" SATA footprint. Early testing shows it keeps pace with similar capacity drives from Seagate and Samsung."

Real capacity is 1.81TB (formatted and ready for use).

ATM they are very hard to find.

[sieve-x]

Let's look again into root cause description in a bit more clear way...

Affected drive model and firmware will trigger assert failure (ex. not detected

at BIOS) on next power-up initilization due to event log pointer getting past

the end of event log data structure (reserved area track data corruption) if

drive contains a particular data pattern (from factory test mess) and if the

Event Log counter is at entry 320, or a multiple of (320 + x*256).

My question:

Maxtorman, is the log file written after each power-up (or POR) and before each shut down? It seems to me the #320 is being reached by many users in about 100 days... can that really be from only occasional events like bad sectors and missed writes? See this time histogram:

http://www.msfn.org/board/index.php?showto...st&p=826575

Maxtorman's response:

The log, if my information is correct, is written each time a SMART check is done. This will always happen on drive init, but can also happen at regularly scheduled events during normal usage, as the drive has to go through various maintenance functions to keep it calibrated and working properly.

_______________________

Event log counter could be written every once in a while for example if S.M.A.R.T automatic

off-line data collection (ex. every 4h) is enabled (it is by default and may include a list of

last few errors like the example below), temperature history, seek error rate and others.

smartctl -l error /dev/sda (data below is an example)

SMART Error Log Version: 1
ATA Error Count: 9 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 9 occurred at disk power-on lifetime: 6877 hours (286 days + 13 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  10 51 00 ff ff ff 0f

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ea 00 00 ff ff ff af 00	  02:00:24.339  FLUSH CACHE EXIT
  35 00 10 ff ff ff ef 00	  02:00:24.137  WRITE DMA EXT
  35 00 08 ff ff ff ef 00	  02:00:24.136  WRITE DMA EXT
  ca 00 10 77 f7 fc ec 00	  02:00:24.133  WRITE DMA
  25 00 08 ff ff ff ef 00	  02:00:24.132  READ DMA EXT

Error 8 occurred at disk power-on lifetime: 4023 hours (167 days + 15 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 71 03 80 01 32 e0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  a1 00 00 00 00 00 a0 02   2d+04:33:54.009  IDENTIFY PACKET DEVICE
  ec 00 00 00 00 00 a0 02   2d+04:33:54.001  IDENTIFY DEVICE
  00 00 00 00 00 00 00 ff   2d+04:33:53.532  NOP [Abort queued commands]
  a1 00 00 00 00 00 a0 02   2d+04:33:47.457  IDENTIFY PACKET DEVICE
  ec 00 00 00 00 00 a0 02   2d+04:33:47.445  IDENTIFY DEVICE

... list goes on until error 5

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
	1		0		0  Not_testing
	2		0		0  Not_testing
	3		0		0  Not_testing
	4		0		0  Not_testing
	5		0		0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

This means that theorically disabling S.M.A.R.T automatic off-line self-test, attributte auto

save (something like: smartctl -s on -o off -S off /dev/sdX) and at system BIOS (before

powering-up the drive again) or even disabling the whole S.M.A.R.T feature set could be

a workaround (crippling S.M.A.R.T would not be a permanent solution becuase it helps

to detect/log drive errors) until the drive firmware is updated.

smartctl -l directory /dev/sda

Log Directory Supported (this one is from an affected model)

SMART Log Directory Logging Version 1 [multi-sector log support]
Log at address 0x00 has 001 sectors [Log Directory]
Log at address 0x01 has 001 sectors [Summary SMART error log]
Log at address 0x02 has 005 sectors [Comprehensive SMART error log]
Log at address 0x03 has 005 sectors [Extended Comprehensive SMART error log]
Log at address 0x06 has 001 sectors [SMART self-test log]
Log at address 0x07 has 001 sectors [Extended self-test log]
Log at address 0x09 has 001 sectors [Selective self-test log]
Log at address 0x10 has 001 sectors [Reserved log]
Log at address 0x11 has 001 sectors [Reserved log]
Log at address 0x21 has 001 sectors [Write stream error log]
Log at address 0x22 has 001 sectors [Read stream error log]
Log at address 0x80 has 016 sectors [Host vendor specific log]
Log at address 0x81 has 016 sectors [Host vendor specific log]
Log at address 0x82 has 016 sectors [Host vendor specific log]
Log at address 0x83 has 016 sectors [Host vendor specific log]
Log at address 0x84 has 016 sectors [Host vendor specific log]
Log at address 0x85 has 016 sectors [Host vendor specific log]
Log at address 0x86 has 016 sectors [Host vendor specific log]
Log at address 0x87 has 016 sectors [Host vendor specific log]
Log at address 0x88 has 016 sectors [Host vendor specific log]
Log at address 0x89 has 016 sectors [Host vendor specific log]
Log at address 0x8a has 016 sectors [Host vendor specific log]
Log at address 0x8b has 016 sectors [Host vendor specific log]
Log at address 0x8c has 016 sectors [Host vendor specific log]
Log at address 0x8d has 016 sectors [Host vendor specific log]
Log at address 0x8e has 016 sectors [Host vendor specific log]
Log at address 0x8f has 016 sectors [Host vendor specific log]
Log at address 0x90 has 016 sectors [Host vendor specific log]
Log at address 0x91 has 016 sectors [Host vendor specific log]
Log at address 0x92 has 016 sectors [Host vendor specific log]
Log at address 0x93 has 016 sectors [Host vendor specific log]
Log at address 0x94 has 016 sectors [Host vendor specific log]
Log at address 0x95 has 016 sectors [Host vendor specific log]
Log at address 0x96 has 016 sectors [Host vendor specific log]
Log at address 0x97 has 016 sectors [Host vendor specific log]
Log at address 0x98 has 016 sectors [Host vendor specific log]
Log at address 0x99 has 016 sectors [Host vendor specific log]
Log at address 0x9a has 016 sectors [Host vendor specific log]
Log at address 0x9b has 016 sectors [Host vendor specific log]
Log at address 0x9c has 016 sectors [Host vendor specific log]
Log at address 0x9d has 016 sectors [Host vendor specific log]
Log at address 0x9e has 016 sectors [Host vendor specific log]
Log at address 0x9f has 016 sectors [Host vendor specific log]
Log at address 0xa1 has 020 sectors [Device vendor specific log]
Log at address 0xa8 has 020 sectors [Device vendor specific log]
Log at address 0xa9 has 001 sectors [Device vendor specific log]
Log at address 0xe0 has 001 sectors [Reserved log]
Log at address 0xe1 has 001 sectors [Reserved log]

It may also be (theorically) possible to check if the 'specific data pattern' is present in system

area IF it can be read from SMART log pages (using standard ATA interface/specification)

so this could be used to create a simple (multi-platform) tool for verifying if a particular

drive is effectively affected by the issue and maybe even used as workaround solution IF

the wrong pattern data or event counter can be changed (ie. read/write).

Edited January 29, 2009 by sieve-x

[jaclaz]

20,000 is too optimist in my opinion. This problem just wasn't bigger, because that "320 thing" is based by "luck".

Yep , the point I was trying to make was that if you can go in a few "logical" steps from 100÷150 reports here on MSFN to a bare minimum of 20,000, rounding everything by defect and using largely speculative "safety" factors, we can say, rightfully and without fearing to be proved wrong by actual figures (when and if they will come to the light), that the phenomenon is HUGE.

Which does not mean it's a matter of millions (though it might be ) but enough to allow me to say that the known title is incorrect:

Seagate boot-of-death analysis - nothing but overhyped FUD

as the issue does not appear that much overhyped (read not at all ) and it's definitely not FUD.

Using Dirk Gently's I-CHING calculator:

http://www.thateden.co.uk/dirk/

anything resulting above 4 becomes "A Suffusion of Yellow", on my personal calculator anything above 20,000 results in "lots" or "too many to count".

I don't care if they represent "only" "some percentage of the drives".

Besides, dlethe while advises the use of common sense:

Use some common sense here, factor in how many 'cudas that Seagate ships in a year, and tell me how many millions of disk drives SHOULD be failing if this is a firmware bug that affects all disks running this particular firmware. Seagate is on a 5-year run rate to ship 1,000,000,000 disk drives ANNUALLY by 2014. If the drive problem was as big as you say it is, then they would have caught it in QC. The problem is a purple squirrel (sorry about the yankee slang -- it means incredibly rare).

In his article:

http://storagesecrets.org/2009/01/seagate-...-overhyped-fud/

seems to be lacking the same.

As long as we are "talking adjectives", everyone is free to have it's own stance and definitions, but when it comes to probabilities and calculating them, checking twice the math would be advised.

Compare the "cryptic" explanation of the "magic number":

So here is what happened. For whatever reason, some of Seagate’s test equipment didn’t zero out the test pattern once the test suite completed, and these disks were shipped. When disks that have this test pattern pre-loaded into the reserved area, and put into service, they are subjected to certain errors, warnings, or I/O activity [remember, I'm not going to tell you what the specific trigger is ..., but the information is available to people who need to know] that results in a counter reaching a certain value. (This is NOT a threshold, but an exact value. I.e., if the magic number was 12345, then 12346 and higher would NOT trigger the bricking logic. Only 12345 triggers it. ). Furthermore, this value is stored in a circular buffer, so it can go up and down over the life of the disk. In order for the disk to brick, the disk must be spun down at the EXACT MOMENT this field is set to this magic number. (The magic number is not an 8-bit value, either). So either on power-down, or power-up, the firmware saw the bit pattern, and the magic number in the circular buffer, and likely did what it was programmed to do … perform a type of lockdown test that is supposed to happen in the safety of the manufacturing/test lab, where it can be unlocked and appropriate action taken by test engineers.

So, let’s say you have a disk with the naughty firmware, that was tested on the wrong test systems at the wrong time. Let’s say that the magic number is a 16-bit number. Then even if you had one of the disks that are at risk, then the odds are > 65,000:1 that you will power the disk off when the counter is currently set to this magic number. If the magic number is stored in a 32-bit field, then buy lottery tickets, because you have a higher probability of winning the lottery then you do that the disk will spin down with the register set to the right value. (BTW, the magic number is not something simple like number of cumulative hours.)

With the one reported from Seagate:

The firmware issue is that the end boundary of the event log circular buffer (320) was set incorrectly. During Event Log initialization, the boundary condition that defines the end of the Event Log is off by one.

During power up, if the Event Log counter is at entry 320, or a multiple of (320 + x*256), and if a particular data pattern (dependent on the type of tester used during the drive manufacturing test process) had been present

in the reserved-area system tracks when the drive's reserved-area file system was created during manufacturing, firmware will increment the Event Log pointer past the end of the event log data structure. This error is detected and results in an "Assert Failure", which causes the drive to hang as a failsafe measure. When the drive enters failsafe further update s to the counter become impossible and the condition will remain through subsequent power cycles. The problem only arises if a power cycle initialization occurs when the Event Log is at 320 or some multiple of 256 thereafter. Once a drive is in this state, there is no path to resolve/recover existing failed drives without Seagate technical intervention.

Since I guess that this latter info was available to dlethe in his "under NDA" documentation, let's see how many x's we have in 16 bit number :

We have 65,536 values, possibly from 0 to 65,535.

In this range, maximum x can be found by resolving:

320+x*256=65,535

Thus:

x*256=65,535-320

x=(65,535-320)/256

x=254.7461 => 254 (plus the 0 value, i.e. "plain" 320 case) => 255 possible values for x

This would place the odds to 65,536:255 => i.e. roughly to 257:1 instead than the proposed "> 65,000:1"

Which would mean that the initial calculation was grossly underestimated.

Again, it is possible that today is not my "lucky" day with math.....

jaclaz

Edited January 28, 2009 by jaclaz

[icefloe01]

jaclaz is teh kewlerest!

[Oliver.HH]

Another attempt to estimate the probability of a drive failing...

Given the "root cause" document posted here by sieve-x, this is what we know:

• A drive is affected by the bug if it contains the defective firmware and has been tested on certain test stations.
  
• An affected drive will fail if turned off after exactly 320 internal events were logged initially or any multiple of 256 thereafter.
  

We don't have the details on how often exactly the event log is written to. Someone mentioned that it's written to when the drive initializes on power-up (though I don't remember the source). If that's true, we would have one event per power cycle plus an unknown and possibly varying number in between.

Given that, the probability of an affected drive being alive after one power cycle is 255/256. After two power cycles it's 255/256 * 255/256. After three power cycles it's (255/256)^3. And so on. While the isolated probability of the drive failing on a single power-up is just 0.4%, the numbers go up when you calculate the probability of a drive failing over time.

Let's assume, a desktop drive is power cycled once a day. The probability of an affected drive failing then is:

0.4% for 1 day

11.1% over 30 days

29.7% over 90 days

76.0% over 365 days

Obviously, I'm ignoring the fact that initially a higher number of events (320) must be logged to trigger the failure. Anyway, this would not change the numbers substiantally and the initial number might be even lower than 256 depending on the number of events logged during the manufacturing process. I'm also ignoring the number of events written while the drive is powered on, as it should not affect the overall probability.

Edited January 28, 2009 by Oliver.HH

[jaclaz]

Obsiously, I'm ignoring the fact that initially a higher number of events (320) must be logged to trigger the failure. Anyway, this would not change the numbers substiantally and the initial number might be even lower than 256 depending on the number of events logged during the manufacturing process. I'm also ignoring the number of events written while the drive is powered on, as it should not affect the overall probability.

Yep , and we don't even have a clear idea on WHICH events are logged and HOW MANY such events take place in an "average powered on hour".

If, as it has been hinted/reported somewhere on the threads, a S.M.A.R.T. query raises an event that is actually logged, we will soon fall in the paradox that the more you check your hardware status the more prone it is to fail.....

Additionally, supposing that certain commands create multiple entries (or "sets" of entries) it is debatable whether "320" has more or less probabilities to be reached.

I mean how probable it is with a "random" number of arbitrary "sets" ( say resulting in 1, 2, 3 or 4 log entries) to reach exactly 320 or to miss it, like in:

317+4

318+3

319+2

I don't think we can find an accurate answer , but we can say that we are definitely NOT in an Infinite Improbability Drive (pardon me the pun ):

http://en.wikipedia.org/wiki/Sub-Etha#Infi...obability_Drive

two to the power of two hundred and sixty-seven thousand seven hundred and nine to one against.

.....

It sounded quite a sensible voice, but it just said, "Two to the power of one hundred thousand to one against and falling," and that was all.

Ford skidded down a beam of light and span round trying to find a source for the voice but could see nothing he could seriously believe in.

"What was that voice?" shouted Arthur.

"I don't know," yelled Ford, "I don't know. It sounded like a measurement of probability."

"Probability? What do you mean?"

"Probability. You know, like two to one, three to one, five to four against. It said two to the power of one hundred thousand to one against. That's pretty improbable you know."

.....

The voice continued.

"Please do not be alarmed," it said, "by anything you see or hear around you. You are bound to feel some initial ill effects as you have been rescued from certain death at an improbability level of two to the power of two hundred and seventy-six thousand to one against — possibly much higher. We are now cruising at a level of two to the power of twenty-five thousand to one against and falling, and we will be restoring normality just as soon as we are sure what is normal anyway. Thank you. Two to the power of twenty thousand to one against and falling."

but rather near, VERY near normality (1:1)....

jaclaz

Edited January 28, 2009 by jaclaz

[Oliver.HH]

Yep , and we don't even have a clear idea on WHICH events are logged and HOW MANY such events take place in an "average powered on hour".

True, but we don't have to know. The probability of a drive failing is the same as long as at least one event is logged per power cycle.

If, as it has been hinted/reported somewhere on the threads, a S.M.A.R.T. query raises an event that is actually logged, we will soon fall in the paradox that the more you check your hardware status the more prone it is to fail.....

No, the chance of a drive failing due to this condition is zero unless it is powered off.

All that matters is that the event counter changes at all from power-on to power-off. It does not matter whether it increases by 1, or by 50 or by any other value as long as such values are equally probable.