Your Chance to Chime In

[jangjong]

Yea I'm with WeeboTech.

 

Many people have been fixing the issue with mem=4095. I will say it's okay for 5.0 final..

[PeterB]

I support Weebo's proposal, too.  Go ahead - publish and be damned!

[SidebandSamurai]

I don't see a problem with moving to final.

 

Provided that all features that were scheduled to have shipped with 5.0 have been adequately tested and work as specified.  It appears that most of these new features have been properly tested.  I don't know what the new features are, so I am in the dark here.  One of them is the Advance Format drives and drives larger than 3GB.  What about the bugs in 4.7 did they re-appear in 5.0?  have they been addressed properly? 

 

Documentation should be updated to reflect new features and any issues that can be resolved by simple parameter fixes for 5.0.  HCL updated to include the hardware known to work with unRAID 5.0.

 

Does the Wiki need to be gone through and to make sure it is current with 5.0 before 5.0 is released?

 

I will remind Tom, that while 5.0 is just about ready for release, It would have been nice to be testing updates to the shutdown script so that it dismounts the array properly.  I have made my point in previous posts.  Again I don't have a call in that.  It should have been addressed long ago, and I don't mean by Wiki or Plugin.  This is small potatoes that can be released in an later fix is suppose, so that should not hold up release in this case.

 

Personally I am not having any problems with this current build and have seen some improvements.  I think with all things considered I would agree that its time to release to 5.0.

 

Of course everyone is saying "release.  release.  release"  I am not agreeing with the masses because that is what everyone else is saying, I am just giving suggestions as a person evaluating the current RC.  Sort of like a Quality Assurance Manager.  Only Tom can be the judge of his product.  If this current code is as good as it gets, excluding minor fixes, then its ready for release.

 

The Slow Write issue is of concern as I just bought the Super Micro board that is having the problem.  Hopefully with the suggestions I have seen, I will not see this issue.

 

I might suggest that a check list be created and each item checked off.  If all items are checked off as completed then its ready to release.

 

Those are my thoughts.

 

--Sideband Samurai

[Juzzotec]

I'm new and have gone against most suggestions here, fix the memory issue before releasing the final.

That's only my opinion

[garycase]

From Tom's first post that started this thread:  "... It seems to work fine ..."

(emphasis on "seems")

 

I think by far the #1 requirement for a "final" is stability.    If it's reliable, then a write slowdown that has a known workaround (mem=4095M) is fine.    For that matter, since it's a 32-bit OS, publish a note that it's limited to 4GB, but can use additional memory on most systems via PAE for buffers, but that some systems are known to have write speed issues with > 4GB.

 

I agree that "final" is NOT just a name, however => it DOES imply a stable, reliable system ... so whether or not you release it depends on just how confident you are in its stability ... "seems to work fine" is not a confidence-building comment 

 

A couple additional thoughts:

 

This is not a "bash Tom" comment, but I agree with the earlier note that a once-every-couple-of-weeks status note (a simple one-liner) would go a LONG way towards installing confidence in the long-term viability of UnRAID.

 

A LOT of us bought SuperMicro C2SEE boards for our servers due almost exclusively to the fact you were using them in your servers and recommended them as superb UnRAID platforms.  I agree -- they are.    I suspect that's why a lot of us look to SuperMicro for additional boards [i have a 2nd server using the superb X7SPA Atom board -- a GREAT choice for up to 6 drives].    But obviously there's at least one SM board that's got a few issues (albeit likely limited to the 4GB issue).    In any event, it would be nice to know what you recommend NOW -- a "known solid platform" that we could confidently KNOW you were testing every release/update on would be really nice to have.

 

[skank]

83% voted for final..

Guess we can expect final then?

For this weekend?

[jaybee]

83% voted for final..

Guess we can expect final then?

For this weekend?

 

There are a couple of minor bugs Tom wanted to "fix for final". I'm not sure if he will do this, or create one final RC just to ensure nothing pops up with any changes. They were:

 

 

 

Just noticed that with the new o+rw permissions now the included ftp server works "out-of-box" what is in part good... but... remember that ftp gives access to all data on the server... and this may be a security problem in cases that a specific user is supposed to access only specific shares etc... as such user using ftp with his login details will have whole access to all data on the server. Think it may be a bad idea to leave this as default for the final version... maybe better idea to disable ftp by default? (but make it easy to be enabled for users that want it)

 

Implementing permissions on FTP would be perfect for sure but guess it would require a lot more work for Tom and probably not for an RC version... that's why I suggested just disabling FTP by default instead.

Very good point.  I'll fix that for final.

 

 

 

 

Anyone know what these log entries mean?  I've not seen them before this version.

 

Jan 12 13:10:55 MediaServer emhttp: title not found

Jan 12 13:14:29 MediaServer emhttp: title not found

Jan 12 13:16:22 MediaServer emhttp: title not found

Jan 12 13:34:07 MediaServer emhttp: title not found

Jan 12 13:49:17 MediaServer emhttp: title not found

Harmless bug, I'll fix for 'final'.

 

 

 

 

There was also the thing with new permissions script and/or writing out to the USB drive again is required.

 

Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.

 

 

[StevenD]

 

Since many of the people complaining about low speed writes have had success with the mem=4095 parameter, I think you can release RC10 as final. You may need to document what's needed if people start having performance issues. Maybe update the syslinux.cfg in the .zip archive to have an additional configuration setting with unRAID (4GB Limit).

 

 

Since I can't change my vote, ill publicly advocate the RC10 to final.

 

+1

 

I cant change my vote either.

 

And THANKS WeeboTech for your help in pointing us to the solution!

[PeterB]

Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.

 

You're probably thinking of the bug which didn't store information about a disabled disk, allowing the disk to come back on line after a reboot.  If there had been an uncontrolled shutdown, then the parity disk was re-written even though the contents of the previously disabled disk were invalid.

[Joe L.]

Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.

 

You're probably thinking of the bug which didn't store information about a disabled disk, allowing the disk to come back on line after a reboot.  If there had been an uncontrolled shutdown, then the parity disk was re-written even though the contents of the previously disabled disk were invalid.

That bug was introduced in the 5.0 series...

 

There are three bugs outstanding in 4.7 we know of.  Two of the three have been addressed in 5.0 so far, I'm not sure of the third.

 

Fixed:

1.  A bug where writes to a disk being reconstructed might be lost.  (existed in all prior versions too, fixed in the 5.0 beta series)

2.  A bug where a move of a temp file that overwrites another file does not un-link from a different disk in same user-share.  (existed since the beginning with user-shares. Detected as duplicate file errors.  Also fixed in the 5.0 beta series,)

 

Unsure:

3.  A bug where the MBR of disks is overwritten with whatever the current "preference" might be if the config/super.dat file is missing and re-created on next start of array. (if the flash drive dies, or someone deletes everything on it and reloads unRAID) this bug has bitten quite a few people on 4.7 making their disks appear unformatted.  Some have lost data with this bug. 

Still unfixed as far as I know.  There is one open thread with a user on 5.0-rc8a with a similar issue where the file system on several 2TB drives was overwritten with GPT partitions usually reserved for 2.2TB and above.  This has not been mentioned in any release notes as being fixed.  I've no idea if it exists in rc10, but I do not want to experiment with my working array. 

The thread is here http://lime-technology.com/forum/index.php?topic=25132.0

 

If that last issue is addressed, go with 5.0 final.    Perhaps include an alternate syslinux.cfg file for those needing the extra parameter.

[TheDragon]

It sounds like a work around has been found for the slow writes issue. Therefore I would also vote to release as final, assuming bug #3 Joe mentions above has been fixed. If it hasn't, I think this one should be resolved prior to final release.

 

Sent from my Nexus 7 using Tapatalk HD

[PeterB]

Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.

 

You're probably thinking of the bug which didn't store information about a disabled disk, allowing the disk to come back on line after a reboot.  If there had been an uncontrolled shutdown, then the parity disk was re-written even though the contents of the previously disabled disk were invalid.

That bug was introduced in the 5.0 series...

 

There are three bugs outstanding in 4.7 we know of.

 

Indeed, but I didn't get the impression that jaybee was referring to old, 4.7, bugs.

 

For certain, I experienced the 'not disabled disk' bug in rc8a, and Tom stated that it would be fixed in 9b (which never appeared).

[Joe L.]

Finally, there was a bug that I think it already fixed in RC10 that Tom originally said would be done in "RC9b" but I think he went straight to RC10. I can't find what the bug was about right now.

 

You're probably thinking of the bug which didn't store information about a disabled disk, allowing the disk to come back on line after a reboot.  If there had been an uncontrolled shutdown, then the parity disk was re-written even though the contents of the previously disabled disk were invalid.

That bug was introduced in the 5.0 series...

 

There are three bugs outstanding in 4.7 we know of.

 

Indeed, but I didn't get the impression that jaybee was referring to old, 4.7, bugs.

 

For certain, I experienced the 'not disabled disk' bug in rc8a, and Tom stated that it would be fixed in 9b (which never appeared).

just pointing out that two of the three known 4.7 bugs have been corrected, but the status of the third is unknown.  There have not been many users of the latest 5.0-rc series that have had a flash drive fail. If the bug still exists, now is the time to address it, before a "final" version is released that includes a fairly serious "known" bug that will bite you when your flash drive has failed.    Tom is currently in the bug-squashing mode...  In my opinion, it would be a mistake to not test for this bug prior to the 5.0-final

 

Joe L.

[Frank1940]

 

That bug was introduced in the 5.0 series...

 

There are three bugs outstanding in 4.7 we know of.  Two of the three have been addressed in 5.0 so far, I'm not sure of the third.

 

Fixed:

1.  A bug where writes to a disk being reconstructed might be lost.  (existed in all prior versions too, fixed in the 5.0 beta series)

2.  A bug where a move of a temp file that overwrites another file does not un-link from a different disk in same user-share.  (existed since the beginning with user-shares. Detected as duplicate file errors.  Also fixed in the 5.0 beta series,)

 

Unsure:

3.  A bug where the MBR of disks is overwritten with whatever the current "preference" might be if the config/super.dat file is missing and re-created on next start of array. (if the flash drive dies, or someone deletes everything on it and reloads unRAID) this bug has bitten quite a few people on 4.7 making their disks appear unformatted.  Some have lost data with this bug. 

Still unfixed as far as I know.  There is one open thread with a user on 5.0-rc8a with a similar issue where the file system on several 2TB drives was overwritten with GPT partitions usually reserved for 2.2TB and above.  This has not been mentioned in any release notes as being fixed.  I've no idea if it exists in rc10, but I do not want to experiment with my working array. 

The thread is here http://lime-technology.com/forum/index.php?topic=25132.0

 

If that last issue is addressed, go with 5.0 final.    Perhaps include an alternate syslinux.cfg file for those needing the extra parameter.

 

This was posted in the release notes for 5.0 rc10:

 

Changes from 5.0-rc9a to 5.0-rc10
---------------------------------
- driver: fixed issue where disabled disk status might not get committed to superblock
- linux: use fuse version 2.9.2 in effort to solve "transport endpoint not connected" problem
- linux: use Realtek version r8168-8.035.00 ethernet driver
- linux: use Realtek version r8169-6.017.00 ethernet driver
- emhttp: fix issue where user-entered "mdcmd set invalidslot" gets ignored upon array start

 

Will the driver fix correct the problem you are referring to?

 

[WeeboTech]

It sounds like a work around has been found for the slow writes issue. Therefore I would also vote to release as final, assuming bug #3 Joe mentions above has been fixed. If it hasn't, I think this one should be resolved prior to final release.

 

Agreed, bug 3 is too serious

[BobPhoenix]

It sounds like a work around has been found for the slow writes issue. Therefore I would also vote to release as final, assuming bug #3 Joe mentions above has been fixed. If it hasn't, I think this one should be resolved prior to final release.

 

Agreed, bug 3 is too serious

Thanks for reminding me of this.  I want to change my vote to not release final if it isn't already fixed now.

[garycase]

Joe,

 

Question r.e. Bug #3:  If you keep a complete copy of the flash contents;  would this still be a potential issue if a flash drive failed and you simply copied the entire contents of the old flash drive to it (except, of course, the UnRAID key file would have to be updated) ??

 

[jaybee]

I thought "bug 3" mentioned above was already fixed in an earlier 5 Beta personally. I was certainly under the impression that all known 4.7 issues were addressed and now non issues in version 5 betas and RC's. Perhaps Tom can confirm. I'm not sure I fully understand the bug anyway to be honest. It sounds like it would only affect someone who's USB stick dies or corrupts?

[Joe L.]

Joe,

 

Question r.e. Bug #3:  If you keep a complete copy of the flash contents;  would this still be a potential issue if a flash drive failed and you simply copied the entire contents of the old flash drive to it (except, of course, the UnRAID key file would have to be updated) ??

That is exactly what I've done on my servers.  It may not be the complete answer, but it can't hurt.

 

Joe L.

[Joe L.]

I thought "bug 3" mentioned above was already fixed in an earlier 5 Beta personally. I was certainly under the impression that all known 4.7 issues were addressed and now non issues in version 5 betas and RC's. Perhaps Tom can confirm. I'm not sure I fully understand the bug anyway to be honest. It sounds like it would only affect someone who's USB stick dies or corrupts?

If you can show me where it was mentioned as fixed, great... but I have a pretty good memory, and read a lot of posts, and I do not remember it being addressed.

 

And, you are right, it seems it only affects those whose USB stick dies or is re-formatted... (potentially everyone) 

 

It is easy to see how it could be missed in the usual regression tests Tom makes.    I suspect the re-writing of the MBRs has always been occurring, but when they all started on sector 63 it never mattered.  Once the alternative partition start sector was introduced in 4.7, I think it surfaced, but the re-write might only occur if the super.dat file was missing.

[p.totton]

It sounds like a work around has been found for the slow writes issue. Therefore I would also vote to release as final, assuming bug #3 Joe mentions above has been fixed. If it hasn't, I think this one should be resolved prior to final release.

 

Agreed, bug 3 is too serious

+1 Need this fixed for final

[dave_m]

I suspect the re-writing of the MBRs has always been occurring, but when they all started on sector 63 it never mattered.  Once the alternative partition start sector was introduced in 4.7, I think it surfaced, but the re-write might only occur if the super.dat file was missing.

 

So if people using sector 63 and a version prior to 4.7 aren't affected, how about people using 5.x with all disks having partitions starting on sector 64?

[Joe L.]

We don't know.  It certainly would not be the case with drives over 2.2TB.  They would never be partitioned for sector 63 or 64.

What is the "default" partition selection on 5.0rc10 if not otherwise selected on a brand new install?

 

The person I'm attempting to assist in the other thread apparently had the superblock in the file system overwritten with a GPT partition on pair of 2TB disks.  He has only recovered one so far, but had to reset it to start the partition on sector 64 before attempting repair.

[dave_m]

I'm actually in the process of setting up a second unraid server and could run through some tests.  If I understand it correctly, the problem should occur if I:

 

1) assign disks, start/stop the array, power off server

2) delete super.dat from flash drive

3) power on the server

 

I can only test with disks under 2TB, but I can report what happens using all sector 63, all sector 64 and mixed.

[Johnm]

In my oppinion. this latest build is still pretty fresh to just slap a "done" stamp on it. there might still be other hidden bugs out there. it needs to go through the wringer...

 

As far as the slow write issue.. I am not seeing this at all.. i have 2 boards that are the same and I am not seeing this issue..