Jump to content

Parity build


NewDisplayName

Recommended Posts

Hi,

im just wondering.

 

I switched a 4 TB with a 8 TB parity (i want to add 8TB drives to array).

 

Parity rebuild already:

Total size: 8 TB  
Elapsed time: 15 hours, 28 minutes  
Current position: 6.74 TB (84.2 %)  
Estimated speed: 123.1 MB/sec  
Estimated finish:
2 hours, 55 minutes

 

 

Just a few questions... 1.) no array drive is spun up... how does he do parity then? 2.) Why its current position is over 4tb? (the biggest drive atm is 4 TB in the array)?

3.) If i click on tools update, i cant switch to branch "next" it selects always "stable". Also, im at 6.5 and it says i can downgrade to 6.5 RC4, that doesnt make sense to me!? (i would like to use latest RC)

 

 

Link to comment

1/2)  a parity check always runs through the full size of the parity drive.    UnRAID assume any space beyond the end of data drives is ‘zeroes’ so which is how it handles the fact that drives can vary in size.    It needs to do the whole parity drive in case you later add a data drive the same size as the parity disk(s).

 

3) There is currently no ‘next’ release which is probably why you cannot switch.    Whether this setting should stay set to ‘next’ in such a case and simply deliver the stable release is a subject for debate.

Link to comment
28 minutes ago, itimpi said:

Whether this setting should stay set to ‘next’ in such a case and simply deliver the stable release is a subject for debate.

 

It is not really a debate.

 

We don't want people to accidentally/unintentionally install a next release, that's why the selection returns to stable when there is no next version available and people need to manually select a next version when it does become available.

 

Link to comment
37 minutes ago, nuhll said:

Do i need to set it now everytime (after i noticed that there is new version) and switch to next?

Only the first time a new RC series is released.  Throughout rc-1, rc-2, rc-x it will stay on "Next" and send notifications that a new version is available until it winds up being on Stable.

Link to comment

You can make what you want. I just look at it on the user side.

 

Also i try to help on forums, so, yes.

 

If i set it to next, i want to have it on next. Ofc standard should be stable. So only the "expierienced" users will set this to next. 

 

As a user its not "normal" that you set something to "next" and it automaticle goes back to "stable" without message. So this is a bad design descicion. 

 

Thanks Squid. Atleast something :D

 

 

Link to comment

The implementation works as follows:

 

Normal setting is STABLE and when a user checks for an update he will be presented with the next STABLE version if available. Say a user is on version 6.4.1 and when he checks for a new version, he is presented with version 6.5.0.

 

When LT releases a (chain of) NEXT versions, which is intended for testing purposes, then the user has to select NEXT to paritipate in these versions. Say LT announces and releases 6.6.0-rc1 then once the user selected to participate in these 6.6.0 RC releases, he will stay on the NEXT version selection and can update and will be notified about any subsequent releases rc2, rc3, etc.

 

We DON'T want a user on a STABLE version 6.5.0 to receive a notification that NEXT version 6.6.0-rc1 is available, but the user will get a notification when 6.6.0 STABLE is available.

 

Countless 'regular' users will select NEXT once and forget to change it back to STABLE. Then nine out of ten people will upgrade without thinking or checking.

The choice was made that upgrading from a STABLE to a NEXT version must always be a deliberate user choice. From a support perspective this makes a lot of sense.

 

Link to comment
21 hours ago, bonienl said:

The choice was made that upgrading from a STABLE to a NEXT version must always be a deliberate user choice. From a support perspective this makes a lot of sense.

I agree.

 

Too bad there isn't a way to make them read the release notes before they can get the update.;-)

Link to comment
11 minutes ago, trurl said:

I agree.

 

Too bad there isn't a way to make the read the release notes before they can get the update.;-)

There is, and it's easy. Encrypt the download with a password that's in the forum's first post for that release, with a link in the upgrade dialog in unraid. Any requests for the password can be answered with that link.

Link to comment
14 minutes ago, trurl said:

Too bad there isn't a way to make the read the release notes

BTW, I''m only suggesting password locking for beta/rc, never stable. The download link on the limetech page could have the password in plain text as well as a link to the forum post. I'm only suggesting the unraid upgrade utility be made a little more difficult to blindly or accidentally follow.

Link to comment
20 minutes ago, Squid said:

or simply the pop up that displays the changelog, forces you to scroll to the bottom to accept in order to download.  Does anybody ever actually read it?

At least they wouldn't be able to complain about not ever seeing the release notes.

Link to comment

I dont know how folks today want this. But i always want my software to be the latest release. 

 

I know there could be harm, but limetech said even they probably wont put a RC out which destroys your house. Most time.

 

What about


Stable (update to the latest stable version, advised)

Next (in the current RC)

latest version (Warning: you might loose data)

 

or something like this. 

 

I feel it pretty annoying to click everytime next also bc the notification from unraid only showed me there was a new release. So i wouldnt even get notification about new RCs, correct?

Link to comment
5 hours ago, bonienl said:

Countless 'regular' users will select NEXT once and forget to change it back to STABLE. Then nine out of ten people will upgrade without thinking or checking.

The choice was made that upgrading from a STABLE to a NEXT version must always be a deliberate user choice. From a support perspective this makes a lot of sense.

The current design is the "best" one for actual users, since the current design assumes that each and every unRaid system is  live system.

 

Lots of people had a reason to jump from stable to test releases earlier because of all Ryzen issues. And the logical conclusion then is that if they follow that progression they should return back to the next stable release and then stay at stable unless they once more make a decision to try intermediate releases.

 

So I think it's 100% ok if some uses feels annoyed that they have to perform a manual step to move to the test branch each time they have upgraded themselves forward to the next stable release.

Link to comment
3 hours ago, nuhll said:

But i always want my software to be the latest release.

Quite a lot of people want the additional condition "latest stable release."

 

There is a huge difference between a unRAID machine used as a toy and as an important server.

Link to comment

Srsly, what are we talking about? If you have very important files, you will backup them anyway, offshore. 


Or am i wrong? And i trust limetech so far that they wont deploy a RC which destroy my server. (if i wouldnt trust them so far, i wouldnt use there product)

 

But anyway, there should be a option for anyone. 

 

Latest stable

Latest RC (current 6.X)

Latest RC 

 

Because why not. I like set and forget options :)

Link to comment
2 hours ago, nuhll said:

Srsly, what are we talking about? If you have very important files, you will backup them anyway, offshore. 

Backup is for restore - so intended to handle file overwrites or catastrophic data loss.

 

Parity drives or disk mirroring are intended for availability - so continued access even after a drive failure.

 

If I have very important files, I want them available. Which means no reboots or other operations that keeps the files offline. Even a small goof that makes a docker not come up means the machine isn't performing the requested task and is thereby failing the availability requirements.

Link to comment

If you're reading the forum regularly, you will know about new releases, and can read the release notes before you make the selection to install the RC.

 

If you're not reading the forum regularly, you probably shouldn't install the RC.

 

I think most would agree with this, and only one arguing against it still.;-)

 

 

Link to comment

This doesnt make sense. I get notification about new update, then i look in forum.

 

Also im not arguing about this. This is just how it should be. Like every (good) software on this planet. Bad software design... useless trouble, how ever you want to call it. 

 

"If I have very important files, I want them available. Which means no reboots or other operations that keeps the files offline. Even a small goof that makes a docker not come up means the machine isn't performing the requested task and is thereby failing the availability requirements."

So why should u choose any auto update then?

 

Link to comment
20 minutes ago, nuhll said:

So why should u choose any auto update then?

Who has implied that I would want any auto update?

Auto update and notification that a new stable version is available are two completely different things.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...