itimpi

What version of unRAID are you using? You might want to check the permissions on the problem folders/files from a telnet session. If running a 5.0 release then you may need to run the newperms script to reset permissions correctly.

That is a good Single rail power supply that can power a reasonable number of drives (I would guess around 20) without issue.

Referring back to the original question then assigning the disks to the unRAID array will destroy their existing contents. This case is different to that where disks already formatted for unRaID can be added without losing their contents. The approach mentioned by OP is therefore the correct way to go. It is perfectly OK to have drives that are not part of the array plugged in to copy data off them. In fact if you are going to do the copies at the Linux level from a telnet session this would give maximum performance compared to copying over the network. You need to be aware, though, that doing so is more prone to user error by you assigning the wrong disk to the array (or pre clearing the wrong disk) and destroying its existing contents. You need to decide if the gain is worth the risk of a slip causing data loss.

No - you want split level 2. Using Level 3 would allow the Season folder (which is at level 3) to be split over multiple disks.

Yes - you will get what you want. The way that I think of Split level is the number of directory levels that are allowed to be replicated on each disk. In your case with a Split Level of 1 this means the Movie folder can be replicated. Any folder that is created under that is constrained to the disk on which it is first created.

Interesting you should say that as it contradicts what I have seen in early reviews. They said the browser only acted as control, but the media was accessed directly from the ChromeCast and that there was no equivalent to Air Play. However it is early days yet so I guess everything is largely rumour and subject to change.

As I understand it the ChromeCast can only play web based content so it may not be relevant to unRAID users who have their media locally.

That option is ignored for drives larger than 2TB. You mention you are running 5.0 RC12a? I would suggest upgrading to the 5.0 RC16c release before continuing. You want to make sure that you have no issues on your system with this release as it is looking increasingly likely that the 5.0 final will not be much changed from RC16c.

If the array is started in Maintenance mode, then you could run reiserfsck --check /dev/md13 Because you are using the array device this would maintain parity (if it happens to be valid at this point). Also because you are using the array device name you do not need to specify the partition as this has already been mapped to the relevant md device.

I seem to remember Tom saying that there were no issues outstanding that would stop 5.0 going final and that the documentation was being worked on.

It depends on the allocation method. If you had the default one of High-Water then that might be true as that method tends to fill up a disk to a pre-determined point before switching to the next disk. Having said that 3TB would certainly result in more than one disk being used, just not necessarily in equal amounts. If you had the Most Free method set then the files are spread more equally across the disks.

The thing to do is check whether rebuilding the disk resets the pending reallocated sectors to zero. If it does you are probably OK. If not you should consider replacing the disk.

Is the system booting at all? You may need to test your BIOS to boot from the USB stick!

I would normally expect the parity check to speed up, and you should not get any errors. You should post a syslog so we can see if any errors are occurring.

Did you rerun the make bootable.bat file? Also what version of unRAID are you trying to use?

I use a command like tail -n 100 -f /var/log/syslog You can also try copying the log file to the flash if you want a copy to survive a reboot. There is also a script (keeplogs.zip) that has been posted a number of times that will redirect the log file to the flash rather than to RAM as is the normal case. However you want to use this sparingly as it can fill up the USB stick with log information, and also shorten its lifetime due to excessive activity.

unRAID would have lost track of the fact that drive had been pre-cleared before using it is a parity drive. Therefore you want to pre-clear it again before adding it as a data disk to minimize array downtime.

Note that the instructions tell you to run it on the disk shares (rather than the user shares) and one folder at a time. How important this is I am not sure, but I guess there must be a reason Tom specified doing at that level of granularity.

Step 1 is optional as a parity disk does not need pre-clearing. However it is probably worth doing as a confidence test on a new drive.

It is worth noting that if you move to the 5.x series of unRAID, then 'root' is no longer allowed as a user for accessing shares.

I would think that anything less than 30MB/s indicates a problem and ranges along the lines of 50-100+ MB/s are typical. It is probably worth attaching a syslog so we can see if you are getting errors reported.

if I remember correctly, that can be aside-effect of installing the SF web plugin.

RAM can go bad. Also possible that earlier releases did not end up using the RAM in the same way so an underlying problem was just not being triggered.

As far as I now there is no outstanding issue that limits you to 4GB of RAM. I would suspect you either have some duff RAM, or the timings/voltage for the RAM you do have are not set correctly in your systems bios.

That sounds slow - I would expect speeds of 50+MB/sec although it can vary with hardware. You should post a syslog so we can see what errors (if any) are being reported.