unRAID Server Release 5.0-rc16c Available

[BRiT]

You need to look to see what disks already have the share directories created since you're using split level 0.

[limetech]

That's a fresh new 3.10.0, and it hasn't yet been put to some serious field testing. I wouldn't look at it before there's a 3.10.5 or something.

My thoughts exactly.

 

But there's 3.9.9 out there, so bumping from 3.9.6 to 3.9.9. may be a good thing. Makes no difference to me though.

I've been following the release notes and nothing really jumps out that it might affect unRaid use.  The next kernel update will probably be when the "official" reiserfs flush patch is produced.

[warpspeed]

Regarding the kernel and netatalk, whilst I'm like everyone else and always like the latest and shiniest with all the bug fixes... reality is, this close to a 5.0 release, I think you should only be updating packages to fix a known issue, or if indeed there's a critical fix to something important (e.g. official reiserfs fix).

 

Things are looking pretty stable and nice right now for a 5.0 release. Don't want to mess that up and end up with another half a dozen RC's

 

If, after a 5.0 release, there are found to be further minor issues... then look at fixing them in a 5.0.1 release or similar.

[garycase]

Regarding the kernel and netatalk, whilst I'm like everyone else and always like the latest and shiniest with all the bug fixes... reality is, this close to a 5.0 release, I think you should only be updating packages to fix a known issue, or if indeed there's a critical fix to something important (e.g. official reiserfs fix).

 

Things are looking pretty stable and nice right now for a 5.0 release. Don't want to mess that up and end up with another half a dozen RC's

 

If, after a 5.0 release, there are found to be further minor issues... then look at fixing them in a 5.0.1 release or similar.

 

Definitely agree.  Barring a significant issue identified in the next few days (perhaps a week), I'd suggest any minor "bugs" be relegated to a "known issues" list for the release notes for v5.0 instead of causing more changes.    With a week of solid operation by everyone trying their hardest to break it [  ], if nobody succeeds it's time to call it 5.0 

[optiman]

upgraded from rc16b, all good so far.

[peter_sm]

All good so far

[stewartwb]

Free Space on user shares still seems to behave the same as rc16b.

What I fixed was this: in calculating free space for a user share, rc16b only tallied free space on each disk where the share currently exists.  In rc16c it also includes free space on each disk where it could potentially exist based on include/exclude masks, and whether it's marked cache-only or split=0.

 

I think there is more work to be done however, in handling the used/free space on the cache disk.

 

I identified one specific issue with the free space computation. 

 

To me, this isn't a showstopper... the recent file integrity bugs were far more critical.

 

Tom, thanks again for all your hard work toward 5.0 Final!

 

For the record, here's the scenario:

• Movie share originally had no disks excluded
  
• Later decided to dedicate disk2 to digital photos
  
• Switched the Movie share to exclude disk2, but left some movie files on disk2
  
• Free Space computation for Movie share still includes all free space on disk2,
  though the share is configured never to write to disk2 going forward
  

In this case, disk2 free space should be excluded from the free space for the Movie share, since the disk is currently configured to be excluded.  Since the Movie share does contain files on disk2, those files should be included in the consumed space computation.

 

I believe the free space computation should be the sum of all free space on all drives on which the share is currently configured to write files, minus the total size of files on the Cache drive waiting to be moved to the share.  The free space on drives containing files served up by the share isn't relevant if the share is no longer configured to write to those drives.

[Helmonder]

Free Space on user shares still seems to behave the same as rc16b.

What I fixed was this: in calculating free space for a user share, rc16b only tallied free space on each disk where the share currently exists.  In rc16c it also includes free space on each disk where it could potentially exist based on include/exclude masks, and whether it's marked cache-only or split=0.

 

I think there is more work to be done however, in handling the used/free space on the cache disk.

 

Should free space calculation be a bit easier, namely: free spaced based on each disk where it could potentially exist based on include/exclude masks...

 

I think you can leave out the part where you calculate free space based on where files currently exist.. If you include that you will also calculate free space on drives that are currently excluded..

[Lacehim]

Updated from 16b to 16c.  Plex played video fine with 16b, and after I updated I tested the same video on 16c and it was freezing and jumping all over the place.  Will retest tomorrow because I'm off to bed.

 

I've never had any issues with plex on unraid, no errors.  Would anything Tom changed effect other plex users not having issues up to 16b?  I know very little about linux and I don't understand what got fixed to stop the transport endpoint not connected issues.

[apgood]

Updated from 16b to 16c.  Plex played video fine with 16b, and after I updated I tested the same video on 16c and it was freezing and jumping all over the place.  Will retest tomorrow because I'm off to bed.

 

I've never had any issues with plex on unraid, no errors.  Would anything Tom changed effect other plex users not having issues up to 16b?  I know very little about linux and I don't understand what got fixed to stop the transport endpoint not connected issues.

 

Using plex with rc16c no issues same as with earlier versions.

 

Sent from my Nexus 4 using Tapatalk 2

 

 

[graywolf]

Great to see this resolved.  Although I haven't personally had the bug, I've followed those who do ... and know it's been "kicking you" a good bit 

 

I presume this means v5.0 is getting CLOSE 

 

Hopefully this will free up some of your time so you can (finally) add UPS support and e-mail notifications  8)   ... perhaps to v5.1 !!  [My suggestion to make e-mail notification simple both for you and the users is to just implement it for <name>@gmail.com ... so everything's already done except the username.  Anyone can get a free gmail account ... and there wouldn't be any configuration hassles  ]

 

I definitely wouldn't be happy with this solution.

 

There is a right way and an easy way, rarely do the two meet.

 

So with your "easy" solution, I would need to set up a gmail account account just for unRaid? Then figure out the forwarding to my actual account? Open up another avenue for additional spam?

 

What about those folks that just don't want to deal with Google? (I know a few). Are they to be left out in the wind?

 

[limetech]

For the record, here's the scenario:

• Movie share originally had no disks excluded
  
• Later decided to dedicate disk2 to digital photos
  
• Switched the Movie share to exclude disk2, but left some movie files on disk2
  
• Free Space computation for Movie share still includes all free space on disk2,
  though the share is configured never to write to disk2 going forward
  

In this case, disk2 free space should be excluded from the free space for the Movie share, since the disk is currently configured to be excluded.  Since the Movie share does contain files on disk2, those files should be included in the consumed space computation.

 

I believe the free space computation should be the sum of all free space on all drives on which the share is currently configured to write files, minus the total size of files on the Cache drive waiting to be moved to the share.  The free space on drives containing files served up by the share isn't relevant if the share is no longer configured to write to those drives.

That  makes sense but you can get into a situation where system reports 0 free space, yet it's still possible to write to the share.  To add a bit more detail suppose you have this arrangement:

 

disk2/Movies/<title-dir>/tiltle.mkv

 

Now you decide to run a nice poster art application that deposits "title.jpg" files in all your "Movie/<title-dir>" directories.  Even though disk2 may be excluded via the share include/exclude masks, if split-level for the share is 1 then those .jpg files for the <title-dir>'s on disk2 will get created on disk2.  So here's a case where free space on disk2 can definitely be utilized, so should it not be included?

 

I think there are two free-space calculations that need to happen:

1. The kind returned by a 'statvfs()' or 'stat -f' call - this is what a program would use to determine if there is space on the file system, and,

2. A utility that presents 'free space' categorized:

- free space per disk, and per disk above 'floor'

- free space on cache for the share

- free space the mover can utilize

etc.

[stewartwb]

For the record, here's the scenario:

• Movie share originally had no disks excluded
  
• Later decided to dedicate disk2 to digital photos
  
• Switched the Movie share to exclude disk2, but left some movie files on disk2
  
• Free Space computation for Movie share still includes all free space on disk2,
  though the share is configured never to write to disk2 going forward
  

In this case, disk2 free space should be excluded from the free space for the Movie share, since the disk is currently configured to be excluded.  Since the Movie share does contain files on disk2, those files should be included in the consumed space computation.

 

I believe the free space computation should be the sum of all free space on all drives on which the share is currently configured to write files, minus the total size of files on the Cache drive waiting to be moved to the share.  The free space on drives containing files served up by the share isn't relevant if the share is no longer configured to write to those drives.

That  makes sense but you can get into a situation where system reports 0 free space, yet it's still possible to write to the share.  To add a bit more detail suppose you have this arrangement:

 

disk2/Movies/<title-dir>/tiltle.mkv

 

Now you decide to run a nice poster art application that deposits "title.jpg" files in all your "Movie/<title-dir>" directories.  Even though disk2 may be excluded via the share include/exclude masks, if split-level for the share is 1 then those .jpg files for the <title-dir>'s on disk2 will get created on disk2.  So here's a case where free space on disk2 can definitely be utilized, so should it not be included?

 

I think there are two free-space calculations that need to happen:

1. The kind returned by a 'statvfs()' or 'stat -f' call - this is what a program would use to determine if there is space on the file system, and,

2. A utility that presents 'free space' categorized:

- free space per disk, and per disk above 'floor'

- free space on cache for the share

- free space the mover can utilize

etc.

It is definitely more complex than your typical file server! 

 

With great power (unRAID shares spanning drives, cache drive, split level) comes great complexity in computing free space.

 

I'd still expect the free space on an excluded drive to be excluded from free space reports for a share.  In my scenario, as it is today, I would get a Disk Full error adding a new movie to that share, despite seeing 400GB of free space due to remaining space on the excluded drive. 

 

I think the "poster art" scenario is an interesting edge case.  I see that you could have the opposite outcome as well: excluded drive is 100% full, included drive show free space remaining, and the Poster Art plug-in fails do add art to the movies stored on the full, excluded drive.  I bet the support requests for these complex scenarios take way too much of your time!

[garycase]

I definitely wouldn't be happy with this solution.

 

There is a right way and an easy way, rarely do the two meet.

 

So with your "easy" solution, I would need to set up a gmail account account just for unRaid? Then figure out the forwarding to my actual account? Open up another avenue for additional spam?

 

What about those folks that just don't want to deal with Google? (I know a few). Are they to be left out in the wind?

 

I'd rather have a simple "fixed" solution than not have a more complex one ... but I understand your concern.    That would simply be a very easy way to minimize what Tom would have to do to provide the capability.    In perhaps 5 minutes you can (a) create a GMail account;  (b) set a filter to automatically put ALL incoming mail except for one specific sender directly into the trash; and © forward mail from the approved sender to any address of your choice.    I just did that for grins .. and it took me less than 3 minutes 

[speeding_ant]

I definitely wouldn't be happy with this solution.

 

There is a right way and an easy way, rarely do the two meet.

 

So with your "easy" solution, I would need to set up a gmail account account just for unRaid? Then figure out the forwarding to my actual account? Open up another avenue for additional spam?

 

What about those folks that just don't want to deal with Google? (I know a few). Are they to be left out in the wind?

 

I'd rather have a simple "fixed" solution than not have a more complex one ... but I understand your concern.    That would simply be a very easy way to minimize what Tom would have to do to provide the capability.    In perhaps 5 minutes you can (a) create a GMail account;  (b) set a filter to automatically put ALL incoming mail except for one specific sender directly into the trash; and © forward mail from the approved sender to any address of your choice.    I just did that for grins .. and it took me less than 3 minutes 

 

Actually, by far the simplest solution is to create a Postfix mail server. It involves 3MB worth of binaries, and an automated setup to make sure it's sending from a valid hostname. Once this is done, providing unRAID has access to the internet, it will just send email to wherever you want. It would come from: root@tower (or whatever your hostname is).

 

This is usually what the other NAS products do, and it makes sense. It requires no additional setting up. Postfix is used around the world, it is highly tested, and it just works. You'd limit the setup so it will only receive email from itself (127.0.0.1).

 

I'm in the middle of a test phase for this now.

[garycase]

I definitely wouldn't be happy with this solution.

 

There is a right way and an easy way, rarely do the two meet.

 

So with your "easy" solution, I would need to set up a gmail account account just for unRaid? Then figure out the forwarding to my actual account? Open up another avenue for additional spam?

 

What about those folks that just don't want to deal with Google? (I know a few). Are they to be left out in the wind?

 

I'd rather have a simple "fixed" solution than not have a more complex one ... but I understand your concern.    That would simply be a very easy way to minimize what Tom would have to do to provide the capability.    In perhaps 5 minutes you can (a) create a GMail account;  (b) set a filter to automatically put ALL incoming mail except for one specific sender directly into the trash; and © forward mail from the approved sender to any address of your choice.    I just did that for grins .. and it took me less than 3 minutes 

 

Actually, by far the simplest solution is to create a Postfix mail server. It involves 3MB worth of binaries, and an automated setup to make sure it's sending from a valid hostname. Once this is done, providing unRAID has access to the internet, it will just send email to wherever you want. It would come from: root@tower (or whatever your hostname is).

 

This is usually what the other NAS products do, and it makes sense. It requires no additional setting up. Postfix is used around the world, it is highly tested, and it just works. You'd limit the setup so it will only receive email from itself (127.0.0.1).

 

I'm in the middle of a test phase for this now.

 

Sounds great ... hopefully you can create a nice simple package for those of us who just want a very easy-to-use solution that will send alerts for key events in UnRAID  [Although I'm sure the next "discussion" will be just what is a "key event" -- some of use just want drive failure notifications; others probably want e-mails for just about anything that changes  ]

 

[speeding_ant]

I definitely wouldn't be happy with this solution.

 

There is a right way and an easy way, rarely do the two meet.

 

So with your "easy" solution, I would need to set up a gmail account account just for unRaid? Then figure out the forwarding to my actual account? Open up another avenue for additional spam?

 

What about those folks that just don't want to deal with Google? (I know a few). Are they to be left out in the wind?

 

I'd rather have a simple "fixed" solution than not have a more complex one ... but I understand your concern.    That would simply be a very easy way to minimize what Tom would have to do to provide the capability.    In perhaps 5 minutes you can (a) create a GMail account;  (b) set a filter to automatically put ALL incoming mail except for one specific sender directly into the trash; and © forward mail from the approved sender to any address of your choice.    I just did that for grins .. and it took me less than 3 minutes 

 

Actually, by far the simplest solution is to create a Postfix mail server. It involves 3MB worth of binaries, and an automated setup to make sure it's sending from a valid hostname. Once this is done, providing unRAID has access to the internet, it will just send email to wherever you want. It would come from: root@tower (or whatever your hostname is).

 

This is usually what the other NAS products do, and it makes sense. It requires no additional setting up. Postfix is used around the world, it is highly tested, and it just works. You'd limit the setup so it will only receive email from itself (127.0.0.1).

 

I'm in the middle of a test phase for this now.

 

Sounds great ... hopefully you can create a nice simple package for those of us who just want a very easy-to-use solution that will send alerts for key events in UnRAID  [Although I'm sure the next "discussion" will be just what is a "key event" -- some of use just want drive failure notifications; others probably want e-mails for just about anything that changes  ]

 

That's the aim, make it as simple as possible.

[Lacehim]

Updated from 16b to 16c.  Plex played video fine with 16b, and after I updated I tested the same video on 16c and it was freezing and jumping all over the place.  Will retest tomorrow because I'm off to bed.

 

I've never had any issues with plex on unraid, no errors.  Would anything Tom changed effect other plex users not having issues up to 16b?  I know very little about linux and I don't understand what got fixed to stop the transport endpoint not connected issues.

 

Using plex with rc16c no issues same as with earlier versions.

 

Sent from my Nexus 4 using Tapatalk 2

 

I rebooted again, went to bed, and tested this morning and all working fine.  Phew.  I don't know what I would do without plex!

[garycase]

... You have them now as plugins, don't you?

 

No.  I do use the CleanPowerDown and APC UPS packages in UnMenu to support the UPS; but never did get the e-mail notification to work after several tries, so haven't bothered with it for a long time.

 

I DO think UPS support and e-mail notifications are "core features" for a NAS.  And apparently Tom agrees ... or at least "agreed" as he was developing UnRAID.

 

A few quotes from Tom in 2005:

 

-------------------------------------------------------

Top 3 features for next release:

1. Security

2. Alerts

3. Standby ability

--------------------------------------------------------

At the present time the only indication of disk failure is on the browser main page; which means you have to look at it once in a while. Having said that, all the code is already "under the hood" to be able to send email alerts. This feature is near the top of the list for the next software release.

--------------------------------------------------------

Yes, UPS support is part of our package that includes shutting down into standby mode after a (configurable) period of inactivity. The UPS control/monitor s/w is brand specific, but most manufacturers provide the s/w we need.

--------------------------------------------------------

 

 

While I like (and use) UnMenu, I think UnRAID should NOT require ANY plugins to work as a good, solid, NAS (it's original design intention) ... and I think that both UPS support to automatically shut down, and e-mail notifications to let the user know that there's an issue are core features that should not require 3rd party add-ins to provide.

 

This is, however, off-topic for this thread ... if you have further comments on it, I'd suggest you add them to the thread here:  http://lime-technology.com/forum/index.php?topic=28212.0

 

[graywolf]

"UPS support" and "e-mail notifications". You have them now as plugins,

< snip >

I'd much rather Tom focuses on core functionality, like double-parity, 64-bit distro, things like that.

 

I agree. There are already plugins for UPS and e-mail.

 

I would prefer Tom spending time on core features at this point (highest on my wish list would be double-parity and plugin manager)

 

These are items that have been on the "Roadmap" for a lot longer and are items that Tom needs to handle whereas UPS/e-mail plugins exist and could be enhanced, rewritten, etc without taking Tom's time.

 

The squeaky wheel doesn't always get the grease, sometimes it just gets replaced 

 

[drawz]

Sounds like Speeding_Ant's e-mail solution will be simple, reliable, and comparable to other NAS devices. At the very least, we should see what he produces before asking Tom to spend his time on this. Why reinvent the wheel?

 

Alternatively, and perhaps the best solution, would be for Tom to adopt Speeding_Ant's work into the official Unraid distribution if he agrees this feature should be part of core functionality. The same goes for UPS support and perhaps even the SimpleFeatures GUI.

[PeterB]

I don't know why you keep yapping about "UPS support" and "e-mail notifications". You have them now as plugins, don't you? Why do you want Tom to redo the same work? If there's something you don't like about those plugins, you have wide community support, and you can even look at them and change them yourself. But if that functionality gets burried in Limetech's closed source, then you'll be at the mercy of one person with limited time resources changing something for you who knows how. I'd much rather Tom focuses on core functionality, like double-parity, 64-bit distro, things like that.

 

Agreed!

[garycase]

... These are items that have been on the "Roadmap" for a lot longer ...

 

I certainly agree that dual-drive failure fault-tolerance is a very desirable feature.  Note this is not simply a "2nd parity" drive, as the computations required for this are much more complex than simple longitudinal parity.  Most implementations use the Reed-Solomon code for the 2nd level of fault-tolerance, but some use a "diagonal parity" approach that's mathematically a bit simpler.    But either approach is a significant increase in the computational requirements and complexity, which I suspect is why it's not yet been implemented.

 

However ... it's hardly "... been on the 'Roadmap' for a lot longer ..." then UPS support or e-mail notifications.  Tom's been promising those features for over 8 years !!

 

[TheWombat]

Installed and parity check underway.

 

Update: Parity Check completed and SysLog looks good. Will shutdown and increase the RAM from 8GB back to 16GB to see if the slow write issue is resolved.

 

TheWombat

 

[madburg]

Upgraded from 5.0RC15a to RC16c

 

1) WebGUI dog slow to load.

2) Disk#17 (sdp) no temps once the WebGui came up, started array, still no temps.

Stopped array and rebooted just incase (should not be the case but didn't hurt), same issue no temp for Drive #17 (sdp).

Moving (clicking) around the WebGui dog slow to load anything.

 

hdparm -C /dev/sdp

/dev/sdp:
drive state is:  active/idle

 

So the drive is definitely spun up (data accessible).