Agree with Bubba -- the "Are you Sure?",  "Are you REALLY Sure?",  "Are you ABSOLUTELY CERTAIN?" kind of dialog usually just gets "clicked through" -- with no more attention paid to it than to software licenses.

 

The vast majority of the "OMG I lost all my data" incidences are due to careless actions that could happen on ANY platform -- and while it's nice to be able to help folks recover when possible, these are NOT things that should result in modifications to UnRAID.    Protecting against dual drive failures is in a completely different category than this -- these ARE very likely ... especially with large arrays of high capacity consumer-grade drives ... and dual parity will make UnRAID a FAR more reliable system.

I agree Tom should not be implementing are you sure prompts. That would be silly. No one in this thread has suggested that.

 

Are there things he should fix? There are a few. And I believe he is working on some of them based on common user problems that I escalated.

 

But in general I thing users need to take it upon themselves to learn more about how things can and do go wrong so they are better able to protect themselves. I agree with BubbaQ and graycase that these users did dumb things. But I don't think that's enough for the moderators to say "it's your own fault" or expect a legion of support people to walk each user through a complex recovery.. We need to make users aware of the dangers and what to do when things go wrong. Judging by the numbers of issues, we are not doing a very good job.

We need to make users aware of the dangers and what to do when things go wrong. Judging by the numbers of issues, we are not doing a very good job.

 

Hold on a second here.

We are not hired help.  I'm all for helping, but let's wait a minute before taking the bullet here.

We assist Limetech, but ultimately the responsibility fails on the company people paid for the product.

I might be willing to accept part of the responsibility if I did not have to voice over and over for the most basic shortcomings to be taken care of.  Until some of the most basic functionality of NAS health is implemented, we cannot do it all on our own. We don't all understand exactly what goes on under the hood.. the devil in the details.

 

There's probably very little we can do to prevent that FORMAT button from being pressed if a mount failure occurs due to a power glitch or some other problem.  While programatically that could be prevented by looking for the pre-clear signature and reporting Mount failure instead of un-formatted.  That format button should not be present unless the pre-clear signature is there.

 

Or even notifying people if the SMART attribute says, FAILING_NOW or has pending sectors.

 

a NAS is supposed to support your data for use and protect it.  unRAID suffices in a cost effective manner in some aspects, but it fails in others. It allows users to make some critical mistakes. 

 

I'm perfectly happy with removing this particular post/response when some crucial issues have been resolved, in the meantime I wont stop voicing the fact that there are pieces missing.

 

I'm not without 'constructive' criticism here, but I'm also wearing thin on suggesting points to make a product better without seeing results. It's been a long time since some of them have been suggested.

 

For the issues where customers shoot themselves in the foot, There could possibly be some kind of embedded help or URL pointing to documentation so that users don't make critical mistakes during a recovery operation.

 

Perhaps a new FAQ on the Wiki and lobbying an update to the webGui when a colored bullet shows up, an url is presented to the FAQ for that error level.

 

Who has, or can, write the necessary Wiki articles?

 

Is there one on the most important SMART attributes? If we start there, can we direct Tom to it saying, monitor these attributes at these thresholds?  (Probably another discussion).

 

Before I take the responsibility of not doing a good enough job for the users, I want a concerted effort to resolve the most common issues in a collective concerted manner with vendor support.  I.E. Updating gotcha and basic health reporting issues.

Absolutely agree with Weebotech => without automatic notifications of failure modes, UnRAID is missing some very key requirements of basic NAS functionality.    WITH those elements, it would be a superb NAS.  And many of these have been promised for YEARS ... but are still not implemented.

Absolutely agree with Weebotech => without automatic notifications of failure modes, UnRAID is missing some very key requirements of basic NAS functionality.    WITH those elements, it would be a superb NAS.  And many of these have been promised for YEARS ... but are still not implemented.

 

I think at the current time we could go without automated notifications to get some forward motion on better array health and visibility.

What we do need in the next version is a some key bug fixes and visibility of data that shows we have a problem.

 

I'll add, without the aid of a plugin. Since emhttp already grabs smart data, it can present key issues.

The reason we've had issues in the past with automating this is the competition of emhttp spinning down drives and the webGui refreshing, causing smartctl to run multiple times in the main line.

 

A few bug fixes, some key features for presentation of data, alerting, dual parity and we can probably expand the array wider.  Although I like the idea of virtualizing multiple instances of unRAID. 

Issue thereafter would be presenting multiple arrays as one big flat user share. Now that would be cool!

I think notifications is a key element in the "better visibility" of status ... not all users check the Web GUI with any regularity.  But I definitely agree you can't protect everyone who simply ignores the advice for protecting their data -- use a UPS; run regular parity checks .. and be sure you correct the errors ...;  backup your data;  replace failed drives IMMEDIATELY; etc.    The Wiki could indeed have better clarity on some of the processes, but we can't protect users from their own lack of attention.

 

I think notifications is a key element in the "better visibility" of status ... not all users check the Web GUI with any regularity.

 

It is, and I agree. My point would be, you have to start somewhere. So starting at an incremental point, make the important information visible, Then design an alerting layer.

 

Help us, help ourselves.  While there are a number of monitor/notify scripts, each has it's pros/cons and can possibly interfere with what emhttp/unraid is doing as far as drive access.

 

From what I remember seeing, MyMain had a good idea in presentation of important smart attributes.

Perhaps a new FAQ on the Wiki and lobbying an update to the webGui when a colored bullet shows up, an url is presented to the FAQ for that error level.

 

Who has, or can, write the necessary Wiki articles?

 

For what it's worth, I think this is something long overdue. The information in the current FAQ/Wiki is very out of date, which leaves users relying on the forums for assistance, which can definitely be hit or miss. While everyone means well, not everyone gives sound advice, and having users rely on this advice can cause more issues than they solve.

 

Additionally, given the volume of forum data that gets created it can be near impossible to find the proper article to address your concern/question, which often causes questions being re-asked repeatedly. Having a proper central repository (FAQ/Wiki) that was reflective of the current 5.0/6.0 states would go a long way to helping users help themselves.

 

As with most issues, this is really the responsibility of LimeTech to provide as they are the official owner/supporter of the product, and hopefully with the expansion of the team this is something that can be addressed. The moderators do a fantastic job of answers questions and assisting users, but those pearls of wisdom often get buried in the flood of miscellaneous conversations that happen.

 

I think this would be a far more effective usage of time than multiple "are you sure" prompts or many of the other suggested ideas (not that there isn't merit in some of them as well).

I agree a generic mail API would be a good addition to unRAID... never said it wouldn't.

 

But if you want to see a cluster of crap, try to do a wizard for entering the parameters to set up an outbound mail connection.

 

Oh, you say, just do Hotmail, Yahoo, gmail, and a couple of other "popular" hosts and you cover 90% of the people..... it is all those fscking exceptions that will kill you.

 

Nearly every week I have someone needing my help to set up mail on an iPhone.... which arguably has one of the easier and better working wizards out there.

 

Thunderbird's wizard is also good conceptually, but I've always had to do manual config every time to get it to actually work.

 

Nearly every week I have someone needing my help to set up mail on an iPhone.... which arguably has one of the easier and better working wizards out there.

 

Wow... It really can't get much easier than the iPhone email wizard.

I believe we are in violent agreement, but that we are debating anyway. See if anyone disagrees with any of the following.

 

1 - Users should take personal responsibility for their servers and need to know more about unRAID to avoid shooting themselves in the foot trying to recover from an issue. There are many addons available that can help but learning to use them BEFORE a problem occurs is important. Monitoring the general support forums for even a few weeks will give users insights into issues their peers are having, and help them recognize similar issues should they happen to them. Moderators are not able to educate the masses individually with each failure, and everyone tires of answering the same questions over and over again.

 

2 - LimeTech has a number of opportunities to address common failure scenarios, send disk failing notifications via email based on various conditions including SMART attributes, and in general make unRAID more helpful in managing and monitoring the health of their arrays. But there are limits and LimeTech is often more focused on new features than addressing the more pedestrian needs, feeling that community addons do a good job in these areas. Whatever the reason, since they are not so proactive in making these kinds of changes. #1 becomes even more important to the individual user.

 

3 - Dual parity will be a powerful new tool to help users recover from dual failure scenarios, which become more likely as disk and array sizes increase. Dual parity may also help users recover from their own stupidity, but #1 is the best way to for a user to protect himself from that. And #1 can be done today while dual parity may or may not see the light of day, and even if it does, we do not know when. And NOTHING LimeTech, the moderators, or other helpful forum users can do will protect an uninformed user from himself!!!

 

4 - Having too many drives protected by a single parity is asking for trouble. Each disk you add to your array adds risk to recovering for even a single drive failure. At some point adding a second array is the better option.

 

Peace.

Well said.

A good summary ... and I agree with all except:

 

... Dual parity will be a powerful new tool to help users recover from dual failure scenarios...

 

The advantage of dual parity isn't to help with dual failure scenarious -- it's to increase the likelihood of a successful rebuild after a single failure ... and to significantly improve the ability to correct parity check errors (since the actual location of the error is then computable, instead of always assuming it's on the parity disk (which is by far the most likely case, but it's nice to be able to confirm that).    The former may be a "dual failure scenario" ... but it can also just be a random uncorrectable bit error -- which would cause a failure with single parity, but will work perfectly with dual parity.  The latter isn't possible with single parity unless you do non-correcting checks (which most users should not do except to confirm a rebuild -- but that's a different argument) and then run a validation against your checksums (if you have maintained checksums of your data) or do a complete comparison against your backups.

 

 

 

 

A good summary ... and I agree with all except:

 

... Dual parity will be a powerful new tool to help users recover from dual failure scenarios...

 

The advantage of dual parity isn't to help with dual failure scenarious -- it's to increase the likelihood of a successful rebuild after a single failure ... and to significantly improve the ability to correct parity check errors (since the actual location of the error is then computable, instead of always assuming it's on the parity disk (which is by far the most likely case, but it's nice to be able to confirm that).    The former may be a "dual failure scenario" ... but it can also just be a random uncorrectable bit error -- which would cause a failure with single parity, but will work perfectly with dual parity.  The latter isn't possible with single parity unless you do non-correcting checks (which most users should not do except to confirm a rebuild -- but that's a different argument) and then run a validation against your checksums (if you have maintained checksums of your data) or do a complete comparison against your backups.

 

Sounds like you agree but are further clarifying. A dual drive failure OR a single drive failure where one of the other drives misbehaves during the reconstruction are both valid use cases for the dual parity feature.

We need to make users aware of the dangers and what to do when things go wrong. Judging by the numbers of issues, we are not doing a very good job.

 

Hold on a second here.

We are not hired help.  I'm all for helping, but let's wait a minute before taking the bullet here.

We assist Limetech, but ultimately the responsibility fails on the company people paid for the product.

I might be willing to accept part of the responsibility if I did not have to voice over and over for the most basic shortcomings to be taken care of.  Until some of the most basic functionality of NAS health is implemented, we cannot do it all on our own. We don't all understand exactly what goes on under the hood.. the devil in the details.

.

.

.

Before I take the responsibility of not doing a good enough job for the users, I want a concerted effort to resolve the most common issues in a collective concerted manner with vendor support.  I.E. Updating gotcha and basic health reporting issues.

 

I subbed to lurk and then I ran across this in slashdot: http://ask.slashdot.org/story/14/05/24/1558242/ask-slashdot-tech-customers-forced-into-supporting-each-other and thought it was apropos.

We need to make users aware of the dangers and what to do when things go wrong. Judging by the numbers of issues, we are not doing a very good job.

 

Hold on a second here.

We are not hired help.  I'm all for helping, but let's wait a minute before taking the bullet here.

We assist Limetech, but ultimately the responsibility fails on the company people paid for the product.

I might be willing to accept part of the responsibility if I did not have to voice over and over for the most basic shortcomings to be taken care of.  Until some of the most basic functionality of NAS health is implemented, we cannot do it all on our own. We don't all understand exactly what goes on under the hood.. the devil in the details.

.

.

.

Before I take the responsibility of not doing a good enough job for the users, I want a concerted effort to resolve the most common issues in a collective concerted manner with vendor support.  I.E. Updating gotcha and basic health reporting issues.

 

I subbed to lurk and then I ran across this in slashdot: http://ask.slashdot.org/story/14/05/24/1558242/ask-slashdot-tech-customers-forced-into-supporting-each-other and thought it was apropos.

 

Some of that thread has merit and hints as reminders, However I do believe limetech is improving.

 

Part of my point is that I don't want to feel obligated for not doing the best job with my free time, when some issues that should be addressed are not interesting enough to finish and solidify support one way or another.

 

I will add that I do believe with recent communications that there will improvement going forward.

 

Don't get me wrong. I'm a big fan of limetech/unRAID. However I also stand from a realistic point of view in keeping data safe, and how a product can/should aid in that goal.

 

On another note, Tom has always made himself available via direct email should the need arise.

I've always felt if the situation was tougher then we could handle, we could address it to Tom and he would aid us or the customer directly.