limetech Posted July 2, 2013 Share Posted July 2, 2013 Hot on the trail of "transport endpoint not connected" issue, but very difficult to debug. It might be solved this afternoon or could take a couple more days. As some of you know, there as been an -rc16 and a -rc16a released: http://lime-technology.com/forum/index.php?topic=28231.0 Release 5.0 'final' is being held up because of this "transport endpoint not connected" issue. There are a handful of minor changes from -rc16a that I could release as -rc16b, or wait and release as 5.0 'final'. Link to comment
limetech Posted July 2, 2013 Author Share Posted July 2, 2013 Changes from 5.0-rc15a to 5.0-16b --------------------------------- - emhttp: fix interpretation of cacheSpindownDelay empty string - emhttp: don't start parity check if "Parity is already valid" checkbox checked - emhttp: enable AVAHI independent of AFP being enabled - linux: patch kernel with corrected reiserfs sync superblock fix - shfs: added additional error checks and messages - slack: log a message to syslog when booted in Safe Mode - slack: added 'config/go-safe' script, invoked in Safe Mode - webGui: misc. changes and cleanup Link to comment
woolooloo Posted July 2, 2013 Share Posted July 2, 2013 I've stuck with official releases, so I'm running 4.7 and I'm out of space. I've been waiting for 5 so that I can bring several 3 and 4 TB drives online, the wait has been miserable. At this point I need 5.0 but if the RC is really so close then maybe I just move forward with that. It seems like there will always be one more issue, seemingly the past several release candidates have all promised to be the last. It's been very frustrating from a user's perspective (at least this user, but based on the results of the prior poll many others probably agree). I've got a 4TB drive going through preclear that will finish in a few hours for my new parity drive. I guess if you decide to officially release 5, I'll install that. Otherwise I'll just install whatever the latest RC is. Link to comment
nars Posted July 2, 2013 Share Posted July 2, 2013 I did voted for "Yes, release -rc16b", there are very important fixes on it, mainly for users still running rc15a... and I guess the most important is they update it ASAP. Also I think it may not be the best thing to do to just release 5.0 final without a public rc first with the changes you added on rc16a... it's ok that a few users (me included) tested it really hard, but still a public rc available for everyone to be able to test it before final I think would be a right thing to do (i.e. make sure the stop array crashes from rc13 are not really back on any system or some unexpected problem that could arise as each system is a system...). You can then look at "transport endpoint not connected" issue with more time. Link to comment
JackBauer Posted July 2, 2013 Share Posted July 2, 2013 Definitely release 16b, not even worth considering IMHO... In that you can release V5 in a week with that remaining defect if needed - but releasing 16b will get even more people testing, to ensure something critical isn't remaining. I've waited a long time for V5, and I know everyone is glad we're almost there. A few more days to do some more valuable testing is well worth it. Link to comment
garycase Posted July 2, 2013 Share Posted July 2, 2013 I'd definitely go with an RC16b ... if for no other reason than to fix the potential data loss issue with 15a (the ReiserFS fix). Not sure if you're going to release v5.0 with your fix or wait for the Reiser maintainer to "bless it" or provide his own ... but there have been quite a few folks who are reluctant to migrate to RC15a due to this issue; but they need > 2TB drive support. I'd release 16b with a note that this, coupled with the transport endpoint fix (and perhaps the "official" Reiser fix) will become v5.0 Link to comment
mejutty Posted July 3, 2013 Share Posted July 3, 2013 I voted yes, I did this because although I did testing an RC16 and 16a The only real tests I ran were based around the data corruption. Would be nice to have the masses run it through the wringer as a just in case. Not everyone uses the system in the same way. Link to comment
JonathanM Posted July 3, 2013 Share Posted July 3, 2013 IMHO, releasing software as 5.0 final without first publicly releasing it AS a RC is bad practice. There should be NO changes except for the name between the last RC and final. Preferably with a period of a week or so of wide usage feedback before blessing the final RC as "final" 5.0. Link to comment
lionelhutz Posted July 3, 2013 Share Posted July 3, 2013 Release RC16b with the transport endpoint issue fixed. Not to sound like an ass, but there have been previous RC versions that were "ready" for release as version 5 found to have a significant issue that meant it was not suitable to be a final version. It would be great if a number of members could run the final release candidate through a series of tests, such as rebuilding and upgrading disks before it's released. On the above note, I'd be curious to know if you have any formal test plan for the software to ensure it maintains data integrity? Link to comment
mr-hexen Posted July 3, 2013 Share Posted July 3, 2013 I voted yes but in reality I don't care what you call if just release something that fixes the RieserFS bug in 15a! Link to comment
ufopinball Posted July 3, 2013 Share Posted July 3, 2013 My stable server is still on 12a, but I have a test server where I can load 16b. As much as I'd like to see 5.0 go final, it's still a good idea to let as many of us do a sanity check ... never know what will shake loose! Rather get it right, than early! Link to comment
madburg Posted July 3, 2013 Share Posted July 3, 2013 Hot on the trail of "transport endpoint not connected" issue, but very difficult to debug. Can you briefly share what you have seen/detected with the "transport endpoint not connected", thanks. Link to comment
SCSI Posted July 3, 2013 Share Posted July 3, 2013 I voted to release -rc16b so I can upgrade from rc12a and test on my server. Thanks! Link to comment
limetech Posted July 3, 2013 Author Share Posted July 3, 2013 Hot on the trail of "transport endpoint not connected" issue, but very difficult to debug. Can you briefly share what you have seen/detected with the "transport endpoint not connected", thanks. The error message is just a symptom that the 'shfs' process has terminated. I have to have plex running a scan and then run a 'find /mnt/user' in a couple windows and once in a while it will fail. But there is nothing output - no syslog messages, no error messages, nothing. Latest run had 'valgrind' watching the process and it has made it through a couple plex scans without failing, and when I terminate the process valgrind shows no memory leaks whatsoever. Another user gets it to fail running rsync, so that's next... Link to comment
itimpi Posted July 3, 2013 Share Posted July 3, 2013 There is one poll option omitted (that is what I would favour). That is to release a rc16b with the intent of making this the final 5.0 (within days) if no new issue is found. I thought of voting for going straight to 5.0 final but would be unhappy with going straight there with a release incorporating any important changes (such as the data loss fix). I think it is bad policy to not have a rc out (for a short period anyway) that is exactly the same as the 'final' release. Link to comment
garycase Posted July 3, 2013 Share Posted July 3, 2013 Reading the other comments, I still vote for an RC16b => but agree it should turn into "final". You should then have an RC17 that includes both the transport endpoint fix AND the "official" ReiserFS fix ... and THAT should then become v5.0 with ONLY a name change after perhaps 7 days of use by the community to ensure no serious latent issues. In other words, RC16b notes would indicate that the only changes anticipated are the transport fix and final ReiserFS fix; and then RC17 notes should indicate that it was intended to become v5.0 after a short period of use by the community. Link to comment
nars Posted July 3, 2013 Share Posted July 3, 2013 Reading the other comments, I still vote for an RC16b => but agree it should turn into "final". You should then have an RC17 that includes both the transport endpoint fix AND the "official" ReiserFS fix ... and THAT should then become v5.0 with ONLY a name change after perhaps 7 days of use by the community to ensure no serious latent issues. In other words, RC16b notes would indicate that the only changes anticipated are the transport fix and final ReiserFS fix; and then RC17 notes should indicate that it was intended to become v5.0 after a short period of use by the community. +1 Link to comment
Frank1940 Posted July 3, 2013 Share Posted July 3, 2013 Another vote for -rc16b. I am running -rc15a. I have been stopping and starting the array to assure that I don't have a the even remote possibility of data loss in the a power loss (and some other event that causes an abnormal shutdown). Plus, it will increase the pool of folks who will be testing an rc version which will have 99.9+% of the code in it that will make into ver 5.0. (There seems to have been a lot of folks who were reluctant to try -rc15a after the data loss issue came up.) If there is some other hidden bug, this will be one last opportunity to uncover it before ver 5.0 is set in concrete! Link to comment
aaronwt Posted July 3, 2013 Share Posted July 3, 2013 I voted for rc16b. I'm planning on purchasing two more pro keys shortly so I'll probably just hold off until these things get straightened out. Then I can expand my unRAID3 to at least twenty drives(for 38TB) and will have a fourth pro license to use as a spare or to setup a 4th unRAID build. Link to comment
dcoens Posted July 3, 2013 Share Posted July 3, 2013 I voted releasing rc16b I have kept up with the RC's until rc16x was released where this was a version only the willing (send tom an email to get a copy) for serious testing of data loss. I think that it would be a fair shake for us "general" users to run rc16b just to be sure of any other conditions that could arise. like nars found out a day or so before rc15 went to final 5. nars figured this was just in the nick of time. Link to comment
apgood Posted July 3, 2013 Share Posted July 3, 2013 Release a 16b is my vote. General user test pool just before final release makes sense as a sanity check, but don't hold final unless critical bug identified like that of nars. Lol... Going through the same thing with a large hr payroll project at the moment. Link to comment
Riot Posted July 3, 2013 Share Posted July 3, 2013 Reading the other comments, I still vote for an RC16b => but agree it should turn into "final". You should then have an RC17 that includes both the transport endpoint fix AND the "official" ReiserFS fix ... and THAT should then become v5.0 with ONLY a name change after perhaps 7 days of use by the community to ensure no serious latent issues. In other words, RC16b notes would indicate that the only changes anticipated are the transport fix and final ReiserFS fix; and then RC17 notes should indicate that it was intended to become v5.0 after a short period of use by the community. +1 +1 Link to comment
Helmonder Posted July 3, 2013 Share Posted July 3, 2013 If there at the moments are patches or changes that will be done on top of the current release (which is the case) then another RC is in order I would say. Should you decide to bring out a version with a few left over issues in it, then V5 could go out... But briging V5 out as the current version + bugfixes without them beiing used in the field en-mass would not be my choice. Link to comment
NAS Posted July 3, 2013 Share Posted July 3, 2013 As far as I can remember theres never been an RC or beta that didnt bring some new trivial issue. We need to keep going with them, we are committed now no matter how long it takes. More RC's please until we are actually ready for V5. Link to comment
Dougy Posted July 3, 2013 Share Posted July 3, 2013 not too long ago it was announced that there would be a new RC in a week and then final a week later...... I think we should know by now that any change may result in a product that is not fit for final. Going straight to final without testing as an RC is not wise..... Link to comment
Recommended Posts