Running unraid v5.0.5 for about a year now; box itself is 3 years, 3 months old, no hardware replacements other than drives.

 

Mobo: SUPERMICRO MBD-X8SIL-F-O

CPU: Intel i3 540 3.06 GHz 4MB LGA1156 CPU BX80616I3540

RAM: Kingston 4GB DDR3 1333

PSU: CORSAIR Enthusiast Series TX650 V2 650W

Case: Antec 1200

Hot Swap Drive Bays: Norco SS-500 x 4

SATA Expansion Cards: Supermicro AOC-SASLP-MV8 8-Port SAS/SATA Add-on Card x 2

Cables:

    0.5m 30AWG Internal Mini SAS 36pin (SFF-8087) Male w/ Latch to SATA 7pin Female (x4) Forward Breakout Cable x 4

 

Just started hearing a two-tone beep from the system, and when I checked the system log, I noticed this right up front:

 

    Nov  5 10:31:24 Tower kernel: CPU1: Core temperature above threshold, cpu clock throttled (total events = 1)

    Nov  5 10:31:24 Tower kernel: CPU3: Core temperature above threshold, cpu clock throttled (total events = 1)

    Nov  5 10:31:24 Tower kernel: CPU3: Core temperature/speed normal

    Nov  5 10:31:24 Tower kernel: CPU1: Core temperature/speed normal

    Nov  5 10:32:13 Tower emhttp: get_filesystem_status: statfs: /mnt/user/CCBD No such file or directory (Other emhttp)

    Nov  5 10:33:33 Tower kernel: mce: [Hardware Error]: Machine check events logged (Errors)

 

 

...and the Machine check events freaked me out enough, but then I scrolled up and started seeing errors like these:

 

    Oct 27 00:04:01 Tower kernel: ata19.00: ATA-8: Hitachi HDS5C3020ALA632,      ML0220F310NG3D, ML6OA580, max UDMA/133 (Drive related)

    Oct 27 00:04:01 Tower kernel: ata19.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32) (Drive related)

    Oct 27 00:04:01 Tower kernel: ata19.00: configured for UDMA/133 (Drive related)

    Oct 27 00:04:01 Tower kernel: sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:5:0: [sdt] Write Protect is off (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:5:0: [sdt] Mode Sense: 00 3a 00 00 (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:5:0: [sdt] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA (Drive related)

    Oct 27 00:04:01 Tower kernel:  sdt: sdt1 (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:5:0: [sdt] Attached SCSI disk (Drive related)

    Oct 27 00:04:01 Tower kernel: scsi 6:0:6:0: Direct-Access    ATA      Hitachi HDS5C302 ML6O PQ: 0 ANSI: 5 (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:6:0: [sdu] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) (Drive related)

    Oct 27 00:04:01 Tower kernel: sd 6:0:6:0: Attached scsi generic sg20 type 0 (Drive related)

    Oct 27 00:04:01 Tower kernel: sas: Enter sas_scsi_recover_host busy: 0 failed: 0 (Drive related)

    Oct 27 00:04:01 Tower kernel: sas: ata13: end_device-6:0: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata14: end_device-6:1: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata15: end_device-6:2: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata16: end_device-6:3: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata17: end_device-6:4: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata18: end_device-6:5: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata19: end_device-6:6: dev error handler (Errors)

    Oct 27 00:04:01 Tower kernel: sas: ata20: end_device-6:7: dev error handler (Errors)

 

 

....and these:

 

    Oct 27 00:04:01 Tower kernel: NX (Execute Disable) protection: active

    Oct 27 00:04:01 Tower kernel: SMBIOS 2.6 present.

    Oct 27 00:04:01 Tower kernel: DMI: Supermicro X8SIL/X8SIL, BIOS 1.1 05/27/2010

    Oct 27 00:04:01 Tower kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

    Oct 27 00:04:01 Tower kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

    Oct 27 00:04:01 Tower kernel: e820: last_pfn = 0x13c000 max_arch_pfn = 0x1000000

    Oct 27 00:04:01 Tower kernel: MTRR default type: uncachable

    Oct 27 00:04:01 Tower kernel: MTRR fixed ranges enabled:

    Oct 27 00:04:01 Tower kernel:  00000-9FFFF write-back

    Oct 27 00:04:01 Tower kernel:  A0000-BFFFF uncachable

    Oct 27 00:04:01 Tower kernel:  C0000-CFFFF write-protect

    Oct 27 00:04:01 Tower kernel:  D0000-DFFFF uncachable

    Oct 27 00:04:01 Tower kernel:  E0000-E3FFF write-protect

    Oct 27 00:04:01 Tower kernel:  E4000-EFFFF write-through

    Oct 27 00:04:01 Tower kernel:  F0000-FFFFF write-protect

    Oct 27 00:04:01 Tower kernel: MTRR variable ranges enabled:

    Oct 27 00:04:01 Tower kernel:  0 base 000000000 mask F00000000 write-back

    Oct 27 00:04:01 Tower kernel:  1 base 100000000 mask FC0000000 write-back

    Oct 27 00:04:01 Tower kernel:  2 base 0C0000000 mask FC0000000 uncachable

    Oct 27 00:04:01 Tower kernel:  3 disabled

    Oct 27 00:04:01 Tower kernel:  4 disabled

    Oct 27 00:04:01 Tower kernel:  5 disabled

    Oct 27 00:04:01 Tower kernel:  6 disabled

    Oct 27 00:04:01 Tower kernel:  7 disabled

    Oct 27 00:04:01 Tower kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

    Oct 27 00:04:01 Tower kernel: e820: update [mem 0xc0000000-0xffffffff] usable ==> reserved

    Oct 27 00:04:01 Tower kernel: found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [c00ff780]

    Oct 27 00:04:01 Tower kernel: initial memory mapped: [mem 0x00000000-0x01bfffff]

    Oct 27 00:04:01 Tower kernel: Base memory trampoline at [c0095000] 95000 size 16384

    Oct 27 00:04:01 Tower kernel: init_memory_mapping: [mem 0x00000000-0x000fffff]

    Oct 27 00:04:01 Tower kernel:  [mem 0x00000000-0x000fffff] page 4k (Errors)

    Oct 27 00:04:01 Tower kernel: init_memory_mapping: [mem 0x37800000-0x379fffff]

    Oct 27 00:04:01 Tower kernel:  [mem 0x37800000-0x379fffff] page 2M (Errors)

    Oct 27 00:04:01 Tower kernel: init_memory_mapping: [mem 0x34000000-0x377fffff]

    Oct 27 00:04:01 Tower kernel:  [mem 0x34000000-0x377fffff] page 2M (Errors)

    Oct 27 00:04:01 Tower kernel: init_memory_mapping: [mem 0x00100000-0x33ffffff]

    Oct 27 00:04:01 Tower kernel:  [mem 0x00100000-0x001fffff] page 4k (Errors)

    Oct 27 00:04:01 Tower kernel:  [mem 0x00200000-0x33ffffff] page 2M (Errors)

    Oct 27 00:04:01 Tower kernel: init_memory_mapping: [mem 0x37a00000-0x37bfdfff]

    Oct 27 00:04:01 Tower kernel:  [mem 0x37a00000-0x37bfdfff] page 4k (Errors)

    Oct 27 00:04:01 Tower kernel: BRK [0x0162b000, 0x0162bfff] PGTABLE

    Oct 27 00:04:01 Tower kernel: RAMDISK: [mem 0x7e011000-0x7fffffff]

    Oct 27 00:04:01 Tower kernel: Allocated new RAMDISK: [mem 0x35c0f000-0x37bfd763]

    Oct 27 00:04:01 Tower kernel: Move RAMDISK from [mem 0x7e011000-0x7ffff763] to [mem 0x35c0f000-0x37bfd763]

 

 

....

See attached syslog for the full context, but both of those blocks are freaking me out a bit, as I have no idea what they mean, nor have I ever seen them before.

 

On Oct. 27, I replaced a 2TB with a 3TB (non-correcting parity check before and after rebuild); no problems, or so I thought.  Parity check started late afternoon on Oct. 27 local system time and completed on Oct. 28 at 8am local system time.  I've been running a non-correcting parity check monthly; no problems.  Unraid has been blissfully perfect since my 5.0.5 upgrade, but now I'm wondering how long these late-night errors that don't seem to draw any attention unless regularly checking syslog have been showing up (or damaging my parity).

 

Also, I'm not sure if this is a factor, but I have a feeling my cache drive is on its last legs, age-wise.  I've been meaning to get a replacement for backup's sake if not instant replacement the past few weeks, but haven't managed it yet.

 

Any advice on how best to proceed safely?

syslog.txt

NIGHTMARE SCENARIO

 

After no response to this post and some searching that indicated those error  messages were nothing to be worried about, I let the issue lie.

 

Even threw a new 4TB on top of a 2TB (parity check before and after, no problem)

 

Well, that 4TB decided to go DISK_DSBL on me at 3am last night during a power surge (yeah, I'm APC-protected; not sure what the hell happened to get it powered off, I only woke up to the beeping)

 

"No problem," I think, "I'll grab another 4TB in the morning and do a rebuild over New Year's Eve."

 

So this morning I'm half-awake and start the array (which takes a minute, and was probably the decision that killed me)

 

Everything's fine, but I notice a whining and clicking noise coming from my tower.  Then I notice a * next to the temperature on Disk 15 in UnMenu.

 

Then I notice 13 errors on Disk 15.  Not the disabled Disk 13, that one's "fine" error-wise post-array start.  13 errors on Disk 15, the * temperature drive.

 

So I go to check the folders that were in Disk 15.  Two of them are fine, but one - containing almost a terabyte of data - appears completely gone.  "Oh, shit."

 

Here I am now, heading to get that 4TB still, but absolutely lost at what's the best next step to take.

 

I assume that with two drives down (one disabled for sure, the other spitting out errors), my rebuild attempt will be worthless.

 

How can I best salvage data from here on out?  Is it too late for BOTH of those damn disks now?

 

Please advise ASAP, and THANK YOU FOR SAVING MY SANITY!

syslog.txt

Unfortunately won't have a lot of time to work on this after the holiday, and something tells me I won't get a lot of response today, so here's my plan:

 

-Pick up two 4TBs on my way home from work

-Try Rebuild on Disk 13

 

No idea what will happen if it fails, but if at that point I still have access to at least some of the files on 13 or 15 (the few that I can currently see), I'll try to salvage those into external storage.

 

At that point, I guess I have to try and start fresh with disks 13 and 15 (the two new 4TBs) and hope that I can identify any new problems with old disks before my next power fluctuation (which seem to be too damn frequent in my town).

 

If I'm making a huge mistake with either one of these steps, I really hope someone advises me against them, but if nothing else I'm leaving a record of this nightmare with these posts.

You have a good approach in getting as much data as you can salvage at this point from those two drives. 

 

Stop at that point and wait for some help from those who are much more of an expert than I am at solving these types of problems.  There is a good possibility that you might not have an any actual disk problems on at least one of the disks.

 

After you recover as much data as possible (by copying to external storage), I would shut the server down.  I would then have a good look at that UPS.  Plug a couple of hundred watts of light bulbs into it and pull its plug from the wall outlet.  If if does not run for four to five minutes (preferably nearer ten with the number of drives you have), I suspect that the battery needs replacement.

 

Were any plugins running at that time (including mover)?  Provide as much information as possible about how you have your server configured as that information may provide some clues to those who can help you. 

Thanks, Frank - I managed to save about 130gb (!) before transfers stopped and the Disk15 status light on my unraid dash went to redball.

 

Weirdly enough, Disk 13, which had been * temperature the whole time I was reading data off of the Disk 13 folders that were still visible (most were missing, and almost everything on Disk 15 was missing, visibly, though windows still reported "full" drives) went to 29 degrees Celsius when Disk 15 was reported dead.  It stayed at that temp (while Disk 15 went *) until I powered down the box.

 

It has remained powered down since that day. 

 

I'm finally getting time to work on this again, and really appreciate your guidance and that of anyone else on the board who can help figure out whether Disk 13 had something other than dead drive occur, because it would be awesome if I could rebuild Disk 15.  Really, really awesome.  Huge pain if I can't, though I will survive it.

 

Tried the UPS test; worked fine.  I have a second UPS I'd been planning to replace the first one with, and will use that moving forward to be safe.

 

I don't believe any plugins were running - all that I have on my cache drive is in "." invisible folders, so mover shouldn't be a factor, and though I've tried Sab and Sick in the past, I don't think either was running at the time, though I guess they could have been.  It's been quite awhile since a shutdown.

 

I'll wait to hear back from someone on here before proceeding, but I do have two 4TB drives ready to replace both Disk 13 and 15 if necessary.  Thanks!

With two dead drives you can't rebuild either of them.    Since you (apparently) don't have backups of your data, I'd just do the following:

 

(1)  Do a New Config with all of the drives EXCEPT the two bad ones assigned as data drives, and let the system regenerate parity, so you'll at least have fault tolerance for the REST of your drives.  You can also include your new drives in this config, so you'll have plenty of free space to copy any recovered data to.

 

(2)  Then do a Reiserfsck on the two bad drives to recover as much of the data as you can ... and copy what you can back to the protected array.

 

Since it seems you always run non-correcting parity checks, I presume that if you ever have any sync errors, you then run a correcting check afterwards to fix them.

 

r.e. your UPS => do you replace the battery at regular intervals?  (if the battery was more than 3 years old that may be why it didn't work properly)

 

Thanks, Gary - so if one disk was DISK_DSBL yet started displaying that temperature again once the other disk died beyond a doubt (no spin, nada), there's pretty much no chance at this point that DISK_DSBL was for anything other than a second (or, temporally, first) dead disk?

Also, yes on the correcting check if errors were found (but I can't remember the last time errors were found before this - a year or more ago, at least).

Hope I'm not stating the obvious re the drive temps.

 

The * means the drive is not reporting a temperature usually because it is spun down.

 

Also, the webgui does not give "real-time" displays of the drive temps. The page has to refresh to get a new result..

There IS some possibility that your issue is due to a bad/loose cable or a power problem ... but even if that's the case, with two bad drives you can't do a rebuild -- and once a drive is marked as bad, if it's a bad cable or power and you fix it, the solution is to rebuild it onto itself ... but you can't do that with two bad drives.

 

So now that I've finished ordering pieces for my new, fault-proof (ha) action machine, it's time to turn my attention back to salvaging what I can from my once-proud alpha box.

 

Just making sure I'm clear on steps:

 

(*) Preclear New 4TB x2

(1) Remove two red balled drives from array, replace with new 4TBs (same capacity as old)

(2) Power up box, new config (builds new parity)

(3) Run parity check

(4) Reiserfsck red balled drives, move salvageable content to new 4TBs

 

My super-paranoid question: if one of my other drives (i.e., a THIRD drive) is close to dying and dies in the parity build (probably unlikely, but this incident has me gun shy), would it be smarter for me to try rebuilding the parity WITHOUT the two disks (removing 8TB from the total data footprint), then once I know I have parity protection again, try adding the two disks?  Longer process, which I'd like to avoid if possible, but losing a third disk would REALLY be a headache with two already down.

So now that I've finished ordering pieces for my new, fault-proof (ha) action machine, it's time to turn my attention back to salvaging what I can from my once-proud alpha box.

 

My super-paranoid question: if one of my other drives (i.e., a THIRD drive) is close to dying and dies in the parity build (probably unlikely, but this incident has me gun shy), would it be smarter for me to try rebuilding the parity WITHOUT the two disks (removing 8TB from the total data footprint), then once I know I have parity protection again, try adding the two disks?  Longer process, which I'd like to avoid if possible, but losing a third disk would REALLY be a headache with two already down.

 

From my experience, the ONLY drive written to during a parity rebuilt is the parity drive.  The data drives are merely read.  It doesn't really make any difference when that third drive fails if you can't do a single read operation from it before it goes belly-up.  If you can get that single read (during a parity rebuilt), the third drive's data is now safe.  While you are recovering drives 1 and 2 data (or as much as possible), that third drive should never even spin up. 

 

If server requires that you get inside to remove and reconnect cables to install the new drives, double and triple check that all of the SATA power and data connectors are are secure.  It is so easy to loosen these cables when you are connecting up another drive.  Even pushing them around can loosen them.

 

Oh, and while you have that case open, clean all of the dust and dirt out the case, CPU cooler fins, the filters, and off the fans. 

That... actually makes a lot of sense.  Sorry for the goofy question, and thanks

 

RE: drives - they're all in hotswap cages, but I'll be replacing the cache drive soon, so when that happens the inside is getting a full cleaning (probably 3 years since I've been inside that beast thanks to the cages).

So this is weird - been a couple of weeks since I dealt with this box, booted up this morning to make sure I was correctly identifying the dead drives I was replacing, and... Now I only have one redballed drive (13).  It seems like I (and unraid) were pretty damn positive both were missing before (per posts above), but now one's back?

 

Unless anyone says "stop, this seems hairy," I'm going to proceed with a replacement of Disk 13 and attempt to rebuild it.

 

What's the worst that could happen if I already accepted I lost 13 and 15, but 15 "dies" while rebuilding 13?  Anything other than 13/15 data loss?

 

EDIT: Since I received errors before I left this box alone for a few weeks, if the disk DOES rebuild, it'll be rebuilding based on parity calculated on a disk with errors, right? Any weird consequences from that, or nothing worse than single disk data loss?

Strange ... but you're correct -- if you attempt a rebuild of #13 onto a new disk and something goes awry, the only thing that will happen is the rebuilt disk won't be correct.    Note that a good rebuild also requires that you have good parity -- was your last parity check error-free?  [Too late to change it if not]

 

After the rebuild, I'd immediately run a non-correcting parity check to confirm it was indeed written okay.

 

 

 

Rebuild started - only weird thing so far, all of my disks show 10 "writes" (usual during my rebuilds), except 15, the "dead" one, showing 12.  No errors anywhere, though.  Headed to work, but will update during lunch or tonight with news.

More weirdness - still no errors or extra writes to "reading" disks, but for some reason my rebuild speed plummeted awhile ago (3MB/s); hung there for a good 20 minutes, now it's hanging steady around 15-20MB/s.  Might be nothing unusual, but struck me as odd.

More weirdness - still no errors or extra writes to "reading" disks, but for some reason my rebuild speed plummeted awhile ago (3MB/s); hung there for a good 20 minutes, now it's hanging steady around 15-20MB/s.  Might be nothing unusual, but struck me as odd.

 

Two things.  First, are you watching the 'pot boiling'?  I know that running the GUI during parity checks will often slow the parity check down due to the accessing of the disks to update the page in the GUI.  Trying exiting out of the webGUI and coming back in an hour and see how things are proceeding.  Second, there may have been issues on reading  an area on one of the disks and the repeated retries to read the data did slow things down. 

 

 

Had NO IDEA about the "pot boiling" impact.  I do that all the time.  Shutting it down now; thanks!

More weirdness - still no errors or extra writes to "reading" disks, but for some reason my rebuild speed plummeted awhile ago (3MB/s); hung there for a good 20 minutes, now it's hanging steady around 15-20MB/s.  Might be nothing unusual, but struck me as odd.

15-20MB/s is still pretty slow runnning through your HBA.

 

AFTER your rebuild is done, you might want to modify your tunables.  You can most likely get that value quite a bit higher.

 

See here for a script to figure it out for you:  http://lime-technology.com/forum/index.php?topic=29009.0  (I always use best bang for the buck settings)

 

Assuming of course that you're not using the array (watching a movie) during the rebuild

Damn, it's CRAWLING now. The rebuild is for a 4tb drive (that was 3tb full); 4tb parity.

 

First 10% was covered between 8:30am and 10:30am.  5 hours later, it's at 16% and was moving at 2MB/s when I checked the webgui.

 

And yet, it's still going... If this disk manages to salvage itself, I'll be damn impressed.

16% in 7 hrs = ~ 1/6th ==> about 42 hrs to do the rebuild.

 

Definitely slow ... but as long as it's still working I'd let it finish.    There are a variety of things that could account for the slow speed -- not really worth trying to isolate, as you do NOT want to stop and restart this.

 

 

Note, by the way, that the "pot boiling" impact is really fairly minor -- the Web GUI updates are electronic access to the drive (to get status, temp, SMART, etc.) ... NOT physical accesses that cause head movement (which can REALLY slow things down).    Actual read/writes to the array during this process are what cause very significant slowdowns -- e.g. watching a movie; writing data to the array; copying data from the array; etc.    One very notable impact folks often don't think about is if you have Cache Dirs running ... when it needs to fill its cache it accesses ALL of the drives sequentially, and this can cause a VERY notable slowdown for 10-20 minutes until it completes that task.    On systems with a LOT of files, this can be constant if there isn't enough memory to hold all of the directories, since it will continually be updated the directory cache.

 

 

AFTER you have rebuilt the data on this drive, it might be well to look at the Health of all your other drives.  You are particularly interested in Perimeters with ID# of 5, 196, 197,198 and 199 under the 'Disk attributes' tab on the Health Page.  Ideally, they should all be zero.  (Don't worry if one or two of the ID# numbers are not reported.)  If you have some that are not zero, ask about them.  (Oh, Perimeter ID# 199 does not indicate a potential drive failure but it is an indication of a problem in other hardware.)

 

You get to the 'Health' page for each drive by double-clicking on the assigned name of the drive under the 'Device' heading on the 'Main' page.

Well, it rebuilt?

 

I tried going into Disk 15 (one I thought dead previously) and lo and behold, a file structure appeared.  Unfortunately, my system hung when I tried going more than one folder deep, but I took this as a good sign, and began a non-correcting parity check.

 

About an hour in, I noticed five disks (all in the same cage in the array) were running a little hotter than the rest (moved a fan accordingly; they're pretty stable in mid-40s now).  I think I have a dead or damaged hotswap cage fan; I've ordered a backup cage for same day delivery just to be safe.  Current plan is to let the non-correcting parity check finish, then assuming everything is OK (or looks OK) there, power everything down, remove ALL the cages (damaged one is on the bottom, and I don't think I can just unscrew and slide that one out without risk to the ones above it - seems like there's some stabilization at play, even with the screws, in this case), replace the sketchy case, reconnect everything (which with Unraid 5.0 shouldn't even matter which order I reconnect the cables, right?), and once it's back up and running, actually go and check the file system again.

 

If it still hangs when I try and go more than one directory deep on Disk 15, I already have a Precleared 4tb ready to replace Disk 15 (since I thought it was dead anyways).

 

Are there any other steps I should take prior to replacing Disk 15 if I take the above steps and everything seems fine?

 

Also, Frank - is that a New GUI option?  I couldn't figure out how to access Health from the webgui I've been using on 5.0.5 (nothing to double click on main, just hyperlinks for each drive), and when I tried installing the New GUI through Utils, it looked like it pulled files down, but doesn't seem any different of a GUI upon reboot...

 

Also, Frank - is that a New GUI option?  I couldn't figure out how to access Health from the webgui I've been using on 5.0.5 (nothing to double click on main, just hyperlinks for each drive), and when I tried installing the New GUI through Utils, it looked like it pulled files down, but doesn't seem any different of a GUI upon reboot...

 

My Bad!  I have two systems here-- one on 5.0.6 and one on Ver6b12.  I am helping people using both and I got confused.  I also use Dynamix as the GUI for my ver 5 system.  (Dynamix is now the standard GUI for ver 6X.)  In the version for 5.X, it has a page called 'Health' where you can run the SMART tests on each disk.  (You have to install the 'Disk Health' plug-in on the Dynamix page.)  You can find a link for it here:

 

    http://lime-technology.com/forum/index.php?topic=30939.0

 

Read the first post for instruction carefully on where to get the Dynamix download.  If you have unMENU installed, it also has SMART report capability under the 'Disk Management' tab.