unRAID Server Release 5.0.4-i386 Available

You by chance have a file named 'syslinux' (with no file extension at all) on your flash root (probably syslinux installer for linux/mac, if you ever manually put it there) ?  If yes, then it is the reason for the error, you can't have a directory and file with same name, you can delete the file anyway.

Anyway, Tom instructions to avoid that sort of problems are:

If you are running 5.0.x, it's only necessary to copy bzimage/bzroot/readme.txt to the flash as before.  You can also copy over memtest if you want the new version.  If you want to make the flash look just like the zip file, then you should make a backup of your config directory, plug flash into your PC (or Mac), reformat, re-install, (don't forget to click make_bootable (PC) or make_bootable_mac), then restore your config backup.

I had occasional problems downloading things from various sites in the past until I installed getright.  It's been 100% solid since.

on this release i seem to have a small issue, when i am in the root level of all the main share my free space shows 3tb but when i go into a subfolder it drops to 2.5tb. i also have a cache drive of 500gb so it looks like it is subtracting that space from the total available. the other issue is if i copy a new movie over and go into that subfolder it shows my free space of the cached drive not the total array. to troubleshoot this i moved back to 5.0.3 and it worked as expected by showing the free space of the total array no matter what folder i was in.

thanks

james

on this release i seem to have a small issue, when i am in the root level of all the main share my free space shows 3tb but when i go into a subfolder it drops to 2.5tb. i also have a cache drive of 500gb so it looks like it is subtracting that space from the total available. the other issue is if i copy a new movie over and go into that subfolder it shows my free space of the cached drive not the total array. to troubleshoot this i moved back to 5.0.3 and it worked as expected by showing the free space of the total array no matter what folder i was in.

 

thanks

james

How are you doing this?  e.g., via console shell commands, on windows network window, other?  ie, how can I reproduce?

thanks!

on this release i seem to have a small issue, when i am in the root level of all the main share my free space shows 3tb but when i go into a subfolder it drops to 2.5tb. i also have a cache drive of 500gb so it looks like it is subtracting that space from the total available. the other issue is if i copy a new movie over and go into that subfolder it shows my free space of the cached drive not the total array. to troubleshoot this i moved back to 5.0.3 and it worked as expected by showing the free space of the total array no matter what folder i was in.

 

thanks

james

How are you doing this?  e.g., via console shell commands, on windows network window, other?  ie, how can I reproduce?

thanks!

sorry I guess that would help  .

i am on windows 7 machine with a mapped drive to a share called "movies" that has all my subfolders. the program i am using is Total Commander. attached is some pics showing the sizes...

thanks

James

Upgraded my 5.0rc16 to 5.04 with no problems.

I do note that "Correct any parity check errors by writing the parity disk with corrected parity" is now CHECKED by-default.

Given that I had an incident with one of my drives about a month ago, I'm inclined to trust my parity disk more than my array as-a-whole, right now.

Is there any compelling reason to LEAVE this checked?

Upgraded my 5.0rc16 to 5.04 with no problems.

 

I do note that "Correct any parity check errors by writing the parity disk with corrected parity" is now CHECKED by-default.

 

Given that I had an incident with one of my drives about a month ago, I'm inclined to trust my parity disk more than my array as-a-whole, right now.

 

Is there any compelling reason to LEAVE this checked?

There has been considerable discussion about this elsewhere, and I doubt anyone wants to revisit it.  Many such as myself feel it should always be checked, and I believe Tom elsewhere has stated something similar.  I've come to agree that in extreme cases, it is possible that a drive bit would be better corrected than the parity bit, but it's a huge problem locating that bit, and another problem to correct it.  I will probably never uncheck that box.  Drive issues are not uncommon, but they are extremely unlikely to result in a case where a non-correcting parity check would be productive.  Others may feel otherwise though ...

Maybe I'm misunderstanding what the parity disk does.  Let's say my monthly parity check reveals 5 errors on my disk#10.  With this option enabled, wouldn't those errors simply be overlooked and, in fact, marked as GOOD by updating my parity disk?  To me, it seems like checking this box is, in effect saying- "Don't trust the parity disk"

??

Maybe I'm misunderstanding what the parity disk does.  Let's say my monthly parity check reveals 5 errors on my disk#10.

The parity check has no way of knowing which drive is in error - all it knows is that one drive (or an odd number of drives) has an error at that location.

With this option enabled, wouldn't those errors simply be overlooked and, in fact, marked as GOOD by updating my parity disk?  To me, it seems like checking this box is, in effect saying- "Don't trust the parity disk"

That is correct.  As has already been stated, Tom is clear that, logically, aside from hardware faults, it should always be the parity which is in error.  The reasoning, I think, is that during an array write, the data drive is written before that parity drive is updated.  Hence, if the parity mismatch occurs as a result of a sudden system halt, the data drives should be trusted.

Moderators -----

Please split this discussion about parity check out out into another thread.  It is out-of-topic and does not belong here. 

I think the thing to realize, consider, understand, whatever ... is that the parity disk and parity checks are not intended to protect against bit errors.  They are intended to protect against drive failures.  Keep in mind a bit error is incorrect data on the data or parity drive and is not the same as a failed r/w or missing drive which causes a drive to be red-balled. 

A parity check does not in and of itself fix a bit error either.  All it does is ensure the data and parity are mathematically consistent so that when a drive is actually red-balled you get exactly what you had the moment before the drive was red-balled; well technically the moment since the last parity check but that is getting nit-picky.  And as Peter said, the assumption is that a detected inconsistency between data and parity makes the assumption, right or wrong, that the data drive is correct.  There is merit to that in certain situations, but in others it is just a 50/50 proposition.

So coming back to the point then of parity, which is to handle the situation when a drive is red-balled because it has failed to come on-line or due to unrecoverable read/write failures.  For context, drives have read/write errors more often than you might think.  But their controller boards handle it gracefully using reattempts and reallocated sectors.  If they are successful the OS and the user are none the wiser unless you go check the SMART report.

So what happens when it is unrecoverable?  In unRaid's case it red-balls the drive and then begins to emulate the red-balled drive using the parity drive to reconstruct data on the fly and continue to allow r/w's.  Once you replace the bad drive the system rebuilds your data using parity and all is good in the world again.

Moderators -----

 

Please split this discussion about parity check out out into another thread.  It is out-of-topic and does not belong here.

I posted the comment HERE because the option was checked after installing the new version.  (MY recollection, was that it wasn't previously checked.)  BEFORE asking the question, I sent a PM to Tom directly, but he didn't respond.  My question stemmed from the fact that I wasn't sure IF the option was enabled for a specific reason after updating the software.  Searching for references to the option would NOT answer that concern- as they would be in-reference-to earlier versions.  I didn't have any indications my parity was invalid...so I just wondered why....

I feel the question (and resulting commentary) is much more relevant to users installing the new software- than discussions of how long it took to download the new version, or what kinds of difficulties were had in downloading  it. 

Moderators -----

 

Please split this discussion about parity check out out into another thread.  It is out-of-topic and does not belong here.

 

I posted the comment HERE because the option was checked after installing the new version.  (MY recollection, was that it wasn't previously checked.)  BEFORE asking the question, I sent a PM to Tom directly, but he didn't respond.  My question stemmed from the fact that I wasn't sure IF the option was enabled for a specific reason after updating the software.  Searching for references to the option would NOT answer that concern- as they would be in-reference-to earlier versions.  I didn't have any indications my parity was invalid...so I just wondered why....

 

I feel the question (and resulting commentary) is much more relevant to users installing the new software- than discussions of how long it took to download the new version, or what kinds of difficulties were had in downloading  it.

For reference next time, Tom is most responsive via emails.

Many thinks for implementing the choice for md_write_method.  I just copied about 8 TB of data around and writing at full disk speeds was just beau-ti-ful.  My array is 8 drives wide at this point, and I am migrating to all 4TB drives, with a 2x2TB RAID0 for cache.

Mow if you just put a toggle on it in the GIU, I'd be all set.

I'm thinking I might hook up a webGui control like this: if this "reconstruct-write" mode is enabled, then if the s/w detects all drives are spun up, it will do reconstruct-write, else if any non-target disk is spun down it will do normal read-modify-write.

If you do that, it should be a tunable option.  Part of my reconfig is to get rid of some dog-squeeze slow 1TB drives I had as temporary xtra storage, and they slowed things down quite a bit.

No issues downloading 5.0.4 or any other release using Firefox on Windows 7.

Upgraded from 5.0rc12a to 5.0.3, and then to 5.0.4.  Parity check speed improved from about 68MB/s on 5.0rc12a to 81MB/s on 5.0.3 and 5.0.4.  I've experienced two issues:

1. I had this issue in 5.0.4, also reported above:

smartmontools drivedb update fails in this release, assumption it has something to do with the addition "- slack: added curl"

root@Tower:~# /usr/sbin/update-smart-drivedb
curl: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
curl: error while loading shared libraries: libcurl.so.4: cannot open shared object file: No such file or directory
/usr/sbin/update-smart-drivedb: download from trunk failed (HTTP error)

I corrected it by downloading this package and installing it in the go script:

http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/slackware/n/curl-7.20.1-i486-1.txz

2. Under 5.0rc12a I was able to preclear a drive (using JoeL's script) without it impacting the array performance.  Under 5.0.3 and 5.0.4, preclearing a drive causes the array to be very slow with writes (2k-5k/sec) even when using mc to move files in a telnet session (no network or user share involvement).  It would also cause stuttering in bluray playback.  The preclearing drive was on a sata controller by itself.  I was able to resolve this by using "nice -n 19" on the preclear and adding the following to the go script:

echo 65536 > /proc/sys/vm/min_free_kbytes

This comes from information in these threads:

http://lime-technology.com/forum/index.php?topic=27942.0

http://lime-technology.com/forum/index.php?topic=27926.0

Update to this version with no issues.

Was there a reversion for smartmontools back to 5.43?  I'm running 5.0.4 and it has smartmontools 5.43.

Was there a reversion for smartmontools back to 5.43?  I'm running 5.0.4 and it has smartmontools 5.43.

I see version 6.2:

root@unraid:~# smartctl
smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

ERROR: smartctl requires a device name as the final command-line argument.


Use smartctl -h to get a usage summary

FYI: Starting with 5.0.5, I left /var/log/packages intact, so that you can see the set of slack packages that make up the release.  Since 'installplg' uses slacks 'updatepkg' command, this should alleviate some of the issues when a plugin tries to install an older package than what's already there.

Note: I know there needs to be an official 'repo' but please let's not discuss that here 

version 5.05 did you say? 

Been using mdcmd set md_write_method 1.

Writing internally I am getting about 30MB/s which is about 10MB/s better. Writing external to internal I am getting about 85MB/s!! No cache drive.

I din't realize there had been a flurry of activity with unRAID. I'm still on the 5.0 Final on my three unRAID setups.

So is it safe for me to upgrade all of them to unRAID 5.0.4?

I din't realize there had been a flurry of activity with unRAID. I'm still on the 5.0 Final on my three unRAID setups.

 

So is it safe for me to upgrade all of them to unRAID 5.0.4?

There's always a (small) chance that you have some unique characteristic in your system that may have an issue with changes ... but in general I'd say you're fine.  The changes between v5.0 and v5.0.4 were primarily resolving minor issues (and implementing a couple new options).    I've seen no problems at all in moving all my systems to the latest version.

LOL security patch 2 days after 5.0.4 release

http://www.samba.org/samba/history/samba-3.6.22.html