NAS

LT are wrong then But seriously I think all we need here is normal nix separation of error states. The reason I bring this up is that after manually tracking down where cache space had gone i noticed that i have had mover errors for weeks so this is based on real world issues. Also it is not my experience here that it only runs once but PECAK is entirely feasible. Will pay more attention and report back.

Some quick feedback. I am new to this plugin. First off my compliments. It is super useful and very powerful Couple of enhancements for consideration: we suggest turning off mover logging which makes sense except that it also removes mover error logging.. we should not be hiding errors. not sure what the best fix would be here. when you enter the settings dialogue it actually kicks off a scan. I would suggest this is a break with the GUI design model and that entering settings should be limited to just that. Activating a scan should be a positive user action especially since it can take tens of minutes to complete. Kudos

Polite bump for (it wont let me quote a quote... silly forum :): tl;dr Even when 100% successfully complete, a preclear run done via the unassigned devices addon only ever has the "cancel" option. Expected behavior would be that cancel state is removed when complete and drive status image changes to pre-cleared.

Agree. This would be ideal but it is disingenuous of me to assume that these wasnt a good reason that this scheme was used in the first place and the same complications still exist today. I think this is the one change that needs to happen soon. My focus on this topic is driven by a strong potential of user data loss and whilst there is an inelegance to users having two types of almost identical disks that are not fully compatible that is an issue that can be addressed in the longer term (much as it irks me about all the time I have wasted moving data to standardize on XFS disks only to now find they are still non standard) I agree here as well and this wording puts a finger on one point I was struggling to make. Also it is important to accept that there is a real difference between the mindset of a user bringing a disk from elsewhere (importing) and one plugging in a disk created on unRAID (native). The user that has stayed native during the whole story may not even think to consider that there may be issues and that is where things can go badly wrong.

@Squid to be fair I specifically and intentionally never said it was a bug in UD for three reasons, 1. I didn't know enough to comment, 2. to the user it makes no difference anyway and 3. I really didn't want to start pointing as that only deflects from the issue.... but that plan kinda back fired lol Anyways based on what I know so far I have to agree with the general sentiment that this must change and soon. It is without question a requirement that there should be absolute compatibility between UD formatted disks and unRAID and if a new common ground needs agreed that better fits with norms then it needs to happen soon. But I stand by my assertation that this is a bug, even if it is intentional and the code is sound; we simply cant have a situation where users can make a simple assumption/mistake and lose a disk of data with one button click. Whatever you need from me you have it because this needs to go away before someone gets hurt.

The bug is that there are scenarios where disks with data could end up being erased. These might be rare but data safety trumps everything. I have not looked into it more since I had a backup to use to recover but I have here (still I think) a disk that was full of data and has ended up unmountable by unRAID and UD. It was (created using UD, mounted using UD, rsync using unRAID, umount using UD and then added to array but not mounted as the format warning stopped me. Also as far as I know unRAID cannot format a disk outside of the array? and if you add it to the array you can no longer remove it without a parity outage. The warning is a good step and I appreciate it as it will no doubt save others. Perhaps someone can explain or point me at more detail as to what is so special about unRAIDs' XFS format options that we cant replicate it? I would rather expend time on a direct fix than a work around or recap of where we were

Add me to the list of people. I am very surprised about this limitation and would like to be pointed at more info. Are we treating this as a bug to fix (because IMHO it is a serious one)

Thanks everyone, I have done so. Anyone know what the back story to this is? 2017.07.09c ..Add: Warning in the format and partition dialog that a UD partitioned disk cannot be added to the array.

That is certainly not the case here. I have never seen anything other than "Stop". For example this is what I see this now:

Polite bump

Apologies if this is covered but this thread is too long to review. When you use preclear, once complete you are left with two confusingly contradictory options: "Preclear Finished Successfully!" and "Stop preclear". Should the "Stop preclear" Red X still be available when preclear is no longer running? Or is the nature of what "Stop preclear" means different after it completes and the wording is just confusing in that context.?

You guys have me convinced now. The Blizard and FreeNAS posts sealed the deal on the argument for me.

Apologies if I missed the reply, this is a popular thread. How do I opt out of this permanently.

Just curious if this is being worked on or at least actively considered. I raise it again as I am currently embarking on a new disk refresh and upgrade (3rd since we started discussing this) and it still maintain that this would both be a genuinely useful / time saving feature but also a Unique Selling Point that your competitors simply cant offer (due to the nature of the RAID they use) should be grabbed with both hands IMHO

How do I permanently opt out of : Preclear Disks Install Statistics Plugin This plugin is used to send statistics anonymously using Google Forms and TOR. Don't worry, you will be asked before sending every report. so that it is not installed by mistake?

given how far unRAID has come I have to say I strongly agree.

Superb summary. Can I suggest that in the interim including some easy indicator in emHTTP as to which of the 3 states ("DX_TRIM" or "DZ_TRIM" or "Unsupported") should be added ASAP. This will raise visibilty in the community and start the natural process of recommendations and more importantly removals

Now that 6.2 is out we need to complete this methodology ASAP. especially in light of the fact 6.2 already is missing one CVE (Curl CVE-2016-7167). Crazy as it sounds the 6.2.1 release clock is already T plus 2 days

There is no more 'call home' starting in 6.2.0-rc5 unless you are using a Trial key. Trial will always require internet access in order to validate. If you want to stay on "stable" releases, you won't have to do anything: the built-in "unRAIDServer.plg" file will trigger updates whenever a new stable release is available. We will also create a post in the Announcement board for new stable releases. If you want to use the latest and greatest development, you will install the "unRAIDServer-next.plg" file. This will trigger updates whenever a new development release is available. We will typically not post announcements for these releases. We will provide more details upon release of 6.2 stable. I would have preferred that we iron out the final wording before 6.2 but I accept that not everything can be the top of the todo list. Lets put a pin in this until 6.2 is released but at that point it has to becomes a priority and certainly needs completed before 6.2.1.

nice work that man

I strongly agree with all of above but at the same time I think if we keep focusing solely on previous mistakes without suggesting specific fixes (preferably in terms of methodology wording changes) then we are doomed to be ignored here and nothing will be fixed. We have made big progress by getting some commitment to change so we should captialise on this and just be more positive to make this a positive toned thread and not a negative one. However feel free to cry havoc if we continute to repeat past mistakes, I plan to but that cant happen until at least 1 month after the first post 6.2 release CVE. To that end I quote my initial comments which we havent addressed yet and a further issue I want to point out again though that since the conversations were split from the RC thread in an endeavour to clear the air and make progress we have made no appreciable difference to any policy. I am happy to help but this has to be a two way street. I wont continue to waste effort talking to myself in the hope someone answers me one day.

We really need to start making moves on firming up and expanding this Release Methodology and the privacy policy. These IMO should be roadblocks for the 6.2 release and not independent "at some future date" deliverables. Currently we are not making any progress at all. I understand everyone is busy but that is not going to change any time soon and if we dont do it we can expect the same kind of upswell as we seen over the last few weeks in the 6.2 release discussions which will sour what should be a big event.

Seems sensible. You might as well think about the "call home" wording now because it is going to be asked soon since all definitions so far have been for beta and RC (which no longer exist so the wording becomes invalid). You are also going to be asked how the community will test all their eclectic setups and hardware if there is no beta cycle.

As spotted by other users here http://lime-technology.com/forum/index.php?topic=51605.msg495311#msg495311 the actual defitnion of RC for unRAID is non standard and needs defined.