Recently (starting with 6.2beta?) if array auto start is set to yes array starts even when there's a missing disk, IMO this can be dangerous when upgrading a disk, I'm used to upgrade a disk while leaving auto star ON, unRAID would detect a missing disk and wouldn't start the array, I just assign the new disk to begin the rebuild.

 

Now, if say while upgrading a disk I bump a cable to another disk in a server with dual parity it will start the array with 2 missing disks, so besides the upgrade I'll have to rebuild another disk.

 

If you want to keep this behavior then please consider setting another option for enable auto start:

 

Always

Yes, if there aren't missing disks

No

 

+1 from me.

While 3 options would be okay, it seems that there should really only be two:

 

Yes

No

 

... and that Yes should ALWAYS mean "Yes, if there aren't any missing disks"

 

I suppose there might be some rationale for "Always" -- it would indeed let the data still be available;  but I'd also think that if there is a missing disk the user should absolutely be made aware of that => and not auto-starting would force them to have a look at the status page and they'd see what the issue was.    Not everyone who uses UnRAID looks at the status page with any regularity.

 

Just throw high availability out the window why dont you? The way the user should be made aware of this is via the notifications. There is no reason for the array to not start if the failures can be compensated by the parity drives.

 

Good point => and a reasonable argument for the "Always" option 

 

... Wonder what percentage of UnRAID users have their systems set up to receive automated notifications ...  (I suspect it's a VERY low percentage)    Perhaps "Always" should actually be "Always - as long as notifications are enabled" 

 

The shares not being up is the only universal notification you know users have and we should always defer to that safest default.

 

To go beyind this actions like this need to be taken in the context of notifications being setup per install. We should not assume users here represent the actual userbase, most wont have more the the very basic setup.

Agree.  While it might be okay to have an "Always" setting, that should definitely NOT be the default.  But the more I think about it, the less I'm convinced we need an "Always" choice.

 

As I noted earlier, simply having two settings [No and Yes, where Yes means "Yes, if there aren't any missing disks"]  means that it's always a conscious action to Start the array if there are problems.

 

As NAS noted, if you boot the array and your shares aren't available (i.e. the array doesn't start), that's the one universal method of ensuring the user LOOKS at the array status page.  That's the most reliable guarantee of a "notification".

 

r.e. Brit's point on high availability =>  The array is going to be available even with a missing/failed disk as long as it's not Stopped.  If it's stopped, it's not going to be available anyway.    Granted, if it's then rebooted, the user would have to manually Start it in this scenario; but in most cases the user will be aware of the reboot process.

 

Note also that if it's a case where high availability is really important, it's not likely there will even be a missing disk => one would hope that as soon as the user/admin KNEW about the missing disk [hopefully through notifications] they would have already resolved it by replacing the failed disk 

 

Let me be perfectly clear, I do not agree with only 2 settings that change the current behavior. That is why if LT makes any changes, it should include the current behavior as an option. Do not take away options from the user.

Remember, however, that the "current behavior" of the stable release (and all previous releases) was to NOT start the array if a disk was missing.

 

As Johnnie noted, this behavior changed with the 6.2 releases -- so there isn't a baseline for "current behavior" in 6.2, since it's not yet been released.

 

Arguments against an "Always" option:

 

(a)  It's NOT the way the system has worked in all previous releases;

 

(b)  Not starting the array with a missing disk is, as NAS noted, the "only universal notification" method => i.e. it will guarantee the user knows they have a missing disk, since they'll have to go to the Web GUI to Start the array and will see the problem;

 

©  It doesn't keep somebody from continuing to use the array with the missing disk => they simply have to manually click on Start ... and thanks to (b) they'll know they have an issue and will (hopefully) get a replacement disk ASAP to replace it (or otherwise resolve the problem) ... so they'll be running "at risk" for the least possible amount of time.

 

I'm not playing your pendantic games.

Bumping this topic for visibility, BTRFS pools don't react like people expect them to when the array autostarts with a missing cache pool member.

@limetech @johnnie.black

Just to be clear, the array auto-starting with a missing array device was fixed some time ago, but it will still auto-start with a missing cache pool device.

As a victim of this behavior I'll vote for this feature.

The cache pool becomes - imho - completely useless if unraid performs an array-auto-start with a missing cache drive - resulting in a complete data loss. 

 

For now I'll follow Johnnies advise to deactivate array-auto-start - but that can only be a workaround - not a solution! 

+1 for "not autostart" option if disk is missing (regardless of missing array or cache pool device).

 

Edited September 2, 20205 yr by hawihoney

+1 here also for option of not auto-starting if disk is missing (array or cache pool device)

Now I don't run cache drives YET, but this is scary! I hope this gets fixed soon!

+1 for me. I had a drive that got disabled and I was trying to find a way to re-enable it without rebuilding. You are supposed to do that if nothing new was changed while hdd was in emulated mode and the array get re-starting at every reboot and tvwas frustrating not to be able to set it so it wouldn’t start with a missing drive.

Edited October 3, 20205 yr by SkinnyV
Typi

54 minutes ago, SkinnyV said:

I had a drive that got disabled and I was trying to find a way to re-enable it without rebuilding. You are supposed to do that if nothing new was changed while hdd was in emulated mode and the array get re-starting at every reboot and tvwas frustrating not to be able to set it so it wouldn’t start with a missing drive.

I am in favor of not autostart if a disk is disabled or missing, but see my replies on your other thread about why you must rebuild anyway.

Yes, I saw your reply, thank you. But I would still prefer for the array not to auto-start after a disabled drive so I don’t keep using the array without noticing.

28 minutes ago, SkinnyV said:

using the array without noticing.

You must configure Notifications to alert you immediately by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

Chiming in here - my situation was a sata card failure, which was replaced - however between the reboots the auto start pretty much killed the cache the same way as 

 

https://forums.unraid.net/topic/94233-solved-rebuild-cache-pool/

 

So despite having no disk failure itself, im now trying to figure out how to rebuild the whole btrfs array to migrate my approximately 2TB of VM data that i have pinned to be exclusively on cache 😅

 

My guess is that, because no drives were really lost, i should be able to perform the recovery in the next 24 hours - but it isn't exactly a pleasant experience, needing to time sink into the recovery process due to such an issue.

My array is now with disabled auto-start, auto-start really should not be default behaviour, if there is a risk of permemenant data loss - which we would block from the UI and warn normally anyway.

Thank you @limetech, I missed it in the rc3 or rc4 release notes but this has finally been implemented, screenshot is from v6.10rc4: