FreeNAS 8.3.0-BETA3 now available

[joeschmuck]

Is there a way to disable the Alert Yellow from flashing just because the pool is not V28? Since V28 is optional, the alert for this specific issue should be something the user can disable. Right now it will condition the user to ignore the flashing alert, even if there is something else wrong. I submitted ticket 1827 to report this potential problem.

Thanks

 

[William Grzybowski]

If you're using 8.3 you should be running V28, unless you're testing it (and in that case the alert system would not matter).

Running v15 and a zpool v28 implementation makes no sense and it should be warned. The idea about v28 being slower does not justify that, this is just a flaw theory, in fact the zfs v28 implementation is slower, even if you're running a zpool v15.
Besides that, the GUI has some zfs screens that assumes you're running the latest pool version, like dedup and zle compression.

 

[mattymuc]

I can't see any performance drops with v28. Everything runs flawless with v28 and at the same speed as v15.
I had to move to v28 because I was not able to replace a failed disks with v15. Resilvering did not stop at 100%, I had to cancel it 5 days after it reached 100%. I tried this 3 times, it never stopped... With v28 the Resilvering process finished without problems.
Thanks for the great work!

 

[joeschmuck]

If you're using 8.3 you should be running V28, unless you're testing it (and in that case the alert system would not matter).

Running v15 and a zpool v28 implementation makes no sense and it should be warned. The idea about v28 being slower does not justify that, this is just a flaw theory, in fact the zfs v28 implementation is slower, even if you're running a zpool v15.
Besides that, the GUI has some zfs screens that assumes you're running the latest pool version, like dedup and zle compression.

True, I'm running 8.3.0-Beta3 on a VM with a V15 pool. My real NAS machine is also V15 pool and running 8.0.4 but I'm hoping to upgrade it to 8.3.0-Release in the coming months.

I didn't realize V28 is the required pool standard for 8.3.0 and I thought it was always an option to convert your pools, not a requirement. When I say option, I mean FreeNAS would run normally with the V15 pool, not they way it currently runs which is functional but expecting V28. With that said, I will remove my ticket and wait to see if people have problems (hopefully not) during the upgrade to V28. I plan to backup all my data to a separate NAS but that will take considerable time, likely days as the old NAS is not a speed demon, before I make the change.

As for dedup, I saw the menu you are talking about, including the compression so I understand what you are saying. Too bad these also couldn't be disabled for a V15 pool. Dedup is fine for a serious business providing they have an enormous amount of RAM to support it unless that has changed too and requires not so much RAM. I myself would ever need dedup nor zle compression but I'm sure others will give it a go and appreciate it.

As a recommendation, maybe the alert window could be a bit stronger in stating V28 is the required pool version for this version of FreeNAS and pool conversion is required however it will operate in reduced capability until the upgrade to V28. Just a thought.

 

[Child]

I'm just curios - why is there any announcement for 8.3.0-RC1 ? It's somehow a bit odd - since the files are online showing yesterday as upload point.

 

[William Grzybowski]

I'm just curios - why is there any announcement for 8.3.0-RC1 ? It's somehow a bit odd - since the files are online showing yesterday as upload point.

Because thats how we roll.

Do not download or install until official announcement, the images might change.

 

[Child]

Well - that's a whacky policy I'd say. But okay :)

 

[joeschmuck]

Because thats how we roll.

Do not download or install until official announcement, the images might change.

That is quite funny but there has been over 2000 downloads alone of the 64bit version. Please make sure that when you formally announce RC1 that if there were any changes, the users out there must download again to ensure they have the latest version of RC1. I myself will hold out until the announcement.

 

[fracai]

Well - that's a whacky policy I'd say. But okay :)

Agreed.
"Are you seeing that critical, data-loss bug using the announced RC? Or one of the pre-announce RCs?"

Is a RELEASE ever re-posted before announcement?

 

[William Grzybowski]

Yes, it is, FreeBSD does that as release engineering.

If you ask me that prevents a possible critical bug hitting say just ~3k people instead ~15k ;)

 

[valesan]

IMHO you always do a great job!
keep it up.

 

[fracai]

Yes, it is, FreeBSD does that as release engineering.

If you ask me that prevents a possible critical bug hitting say just ~3k people instead ~15k ;)

True, though I think it'd be clearer if an announcement always coincided with a posting and, more importantly, changing an image always changed the name. Even something like BETA3-r1.

I get that it's a different strategy than I'm used to, just seems odd to me.

Thanks.