evans036

perhaps an intermittent problem caused by bad cable?

if i remember correctly, the 4.7 bug may corrupt data if data is written to the array whilst a data drive is being rebuilt from the parity drive. were you writing data to the array whilst the new data drive was being rebuilt? if not, you need to figure out if it is the parity drive at fault or is it the data drive. you might want to try a reiserfsck on the data drive. perhaps smart reports could indicate drive issues. look in the syslog for drive related IO erros too if you still have your old data drive, maybe do a hash verification using md5deep using the hash file from one drive to verify the hash on the other. hope some of this helps, steve

try logging into your unraid server using a direct attached keyboard/monitor and then issue command: ifconfig this should display (amonst other things) your ip address. there will be a section likely called 'eth0' which should look something like: eth0 Link encap:Ethernet HWaddr 00:21:5E:C4:0A:6C inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::221:5eff:fec4:a6c/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:4649351622 errors:14 dropped:1890787648 overruns:0 frame:14 TX packets:5768769300 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1265032277532 (1.1 TiB) TX bytes:6455141397173 (5.8 TiB) then try pinging that ip address (in eg above that would be 192.168.1.11) from another computer. hope this helps, steve

i should have mentioned: i am logging in under 'guest' steve

to quite from a prev article: "On Friday, 5.0 beta8c was released which included a critical bug fix addressing an issue with data rebuilding and subsequent “Parity Check” sync error. Apparently, this issue also exists in 4.7 “Final” " my understanding is that data can become corrupt under this circumstance. it has been fixed in the beta, but not final. hope this helps, steve

this worked 'out of the box'. backing up my wifes mac as i type. thanks a lot. steve

your split level & directory structure and other parms can affect which disk data is written to. during the copy, watch the disk activity (unmenu-> disk performance, for example) to see where the data is going. hope this helps, steve

in the guimenu there is an option to see open files. open the file via the share using your player (or whatever) and then see what files are open. it will list the path which includes the disk. hope this helps, steve

i had a very similar problem and changed the 'settings->local master' from 'no' to 'yes' hope this helps, steve

with a split level=1, maybe its b/c of your directory structure under 'movies' (eg only one directory would do that). steve

under 'settings' in the 'indentification' section there is a 'local master' setting. changing that to 'yes' may help. good luck, steve

no wifi?

are they truly mounted? try going into linux and typing: df this should display all mounted drives you should be able to unmount them using the 'umount' command good luck, steve

i just looked. i dont think the syslog IS on the thumb drive. so i guess you have no diagnostics at this point. sorry for the misinformation. steve

ouch. is the linux syslog stored on the thumbdrive? if it is you might want to stick the thumb drive into another computer to get at the syslog to get some idea of what caused such a failure. location would be somthing like /var/log/syslog alos, you might want to do the memtest option that is presented at unraid startup good luck, steve

try #2 how about something like: dd if=/dev/sde bs=8k of=/dev/null where /dev/sde is replaced by your device steve

sorry: brain fart here. steve.

roger on the static ip by attaching a console, i meant to physically connect a monitor good luck, steve

try attaching a console. do you get a prompt? is it possible the ipaddress of the server has changed?

perhaps a reiserfsck would be faster?

you wont have the same file on two disks - but it will be arbitrary as to which a file is stored steve

that partly depends on the structure of your data & the split level value. for example a split level of 1 when all of you data resides under the same 1st & 2nd level directory would result in this behavior (ie all of the data going to the one disk). if you dont care about co-locating data on the same disk, then set the split level to some arbitrarily high number (that exceeds your greatest directory depth). you should then see the data spread across your disks as you had oriiginally expected. good luck, steve

i thought that maybe it was 'fill up' and the min free was set too small. but 'high water' should always work. have you tried explicitly writing to the 'disk2' share for example (just to see if you can write to it). since i dont know the structure of your data, you might want to try a split level of 9999 to ensure any level can go on any disk. does the server need to be restarted for these changes take effect? good luck, steve

you show allocation method as: Allocation method: High-water Most-free Fill-up it should be one of these. which one is it? thanks, steve

what is your allocation method?