I realised after my server lost power again today that the "Last checked on.." on the WebUI only shows when the last parity check was STARTED and not necessarily COMPLETED. This can lead to a false sense of security if you cancel a parity check as it can show a recent completed check with no errors found. A short term fix to this might be to only update the date/time based on a completed check rather than a started check. I understand if this is easier said than done

 

A parity check should be completed after a power loss which is why unRAID automatically starts one and this is is a good thing.. however since I usually only notice my server wasn't shut down properly when I am about to start using it (writes) I tend to stop the check and run it later in the evening when there is little interruption. For me being able to schedule a parity check for a time when the server is not being used would be great as I usually just do it before I go to bed. I am aware that the server can be read during a check although in my experience you can't write during this time.

 

More information that could be displayed could be something like:

 

Parity Status

 

• Last parity check on 12/6/2011 5:19:05 PM, finding 7 errors. Parity check was manually interrupted at 10.4% and your array may not be protected
  
• Last completed parity check: 11/6/2011 2:12:10 PM, finding 0 errors.

[br]

• Schedule a parity check for: 13/6/2011 @ 1:00:00 AM

[x] (Checkbox) Prevent mover from running during check

 

Any thoughts/ideas?

Good idea.

Good idea.

I agree.

I think if Tom had someone working on the GUI/Automation features for a month, a lot of these little issues/oversights would disappear. Cummon Tom, just hire some grad for a month to modernise your product! I created the base of SimpleFeatures in just over 15 hours, can't be that bad.

Any more opinions on this feature/update? Would love to hear more feedback/comments and if more people out there believe it is something worth adding.

 

Not that Tom doesn't have enough on his plate right now :-)

I noticed this in my first week of testing.

 

I would love a bit more info in the parity status information bar.

 

I do not personally need the one off schedule task, but i can see its benefit for others.

 

I am also wondering if the auto repair after a crash "check box" should be defaulted to checked or not? I don't know if the error is the dive data or the parity data that is wrong and which one the repair fixes.

I do not personally need the one off schedule task, but i can see its benefit for others.

 

It could be really useful as a tool to schedule now, sometime in the future, or a monthly cycle.

 

 

What is also needed is a basic smart analysis of all the drives.

Even the most basic NAS environments look at the SMART info to see if a problem is arising.

What is also needed is a basic smart analysis of all the drives.

Even the most basic NAS environments look at the SMART info to see if a problem is arising.

 

Correct me if i'm wrong but I believe version 5 does display SMART status, or did you mean a type of regular SMART check to see if a drive is failing?

What is also needed is a basic smart analysis of all the drives.

Even the most basic NAS environments look at the SMART info to see if a problem is arising.

 

Correct me if i'm wrong but I believe version 5 does display SMART status, or did you mean a type of regular SMART check to see if a drive is failing?

 

Since I've only seen the very early betas I may be missing something.

In any case I've just fired up 5.1 and it seems you can get the smart status if you drill down to the drive.

This is good, I must have forgot about that.

 

Now from the front panel. I would like to see a general health icon so that if there are issues, you can get an early bird's eye view.  This may be present in the latest versions. I'll have to download the latest and greatest to see.

I know one of the things I always want to know is the actual linux /dev/sd? id.

Just bumping this topic again to see if there is any interest in making some of these changes, I will send a link to Tom as well although with 5.0 in RC-2 at the moment I'm sure he has plenty on his plate right now 

Just bumping this topic again to see if there is any interest in making some of these changes, I will send a link to Tom as well although with 5.0 in RC-2 at the moment I'm sure he has plenty on his plate right now 

+1

 

Seems like bonienl has added a bunch of these requests into SimpleFeatures already..  Just sayin' 

Why prohibit the Mover from running during a parity check?

Why prohibit the Mover from running during a parity check?

On the 4.7 series the bug still exists where if you write to the array at the same time a parity calc is occurring you run the risk of the dirty buffer of a disk block in the disk cache will be marked as clean and the data not written to the data disk.  When performing a parity check/calc, or when re-constructing a drive, we are best to not write to the disk being reconstructed/checked.    This issue was fixed in one of the middle  5.0 betas, but is still broken in the 4.7 version.

 

The other reason, for all releases, is to prevent the two processes from causing massive seeks on the parity drive, drastically slowing the parity check.

 

 

I'm not sure if this is related but whenever I write to the array during a parity check unRAID has a tendancy to crash. I haven't managed to cap a log of this yet and last time i did a tail -f it showed absolutely nothing out of the ordinary, the box would just become unresponsive w/ black screen and need a hard reset. I figured it was just a bug and I could live working around it, no other issues otherwise - all drives have been tested in full & memtest for 24+ hours, perfect temps, no plugins/addons at all. I have no problems reading from the array during a parity check.

Could we extend this to doing 10% of the check at a time?

 

So instead of doing ~7 hours in one go, you can do 10% of the array every day.

 

I'd like this method, so that after my mover script has run at 7am, the parity check does another xx% of the check for an hour.

 

This way your parity is never more than 7 (or whatever % of check a day you doper day) days checked/out of date?

Could we extend this to doing 10% of the check at a time?

 

So instead of doing ~7 hours in one go, you can do 10% of the array every day.

 

I'd like this method, so that after my mover script has run at 7am, the parity check does another xx% of the check for an hour.

 

This way your parity is never more than 7 (or whatever % of check a day you doper day) days checked/out of date?

Interesting idea.  It might have saved my drives from overheat when a fan died.  I might have been able to see they were over heating (60c+) before they were affected.  Now I'm trying to come up with enough replacement drives for the 12 that got overheated before they completely die.