shanecole

I've always appended checksums to my files and I think you are forgetting that XBMC is using the filename of the MKV to create the other files including the checksum you had appended to the end of the MKV... so those files are never going to have a valid CRC32 as it's not their CRC, it's the MKVs.

Thank you for the suggestion! So far, all corrupt files have been to one disk, but thats the most empty disk and has been taking the majority of writes. I will keep track of whenever it happens and see if it is common to one drive or if on different drives to one controller. In any case I bought a set of new SATA cables and am ready to replace willy nilly!

I am faced with an intermittent issue where a file that I move to my server when read back from the server no longer has the correct CRC32. Having noticed it happen a few times (more often on larger files) paranoia has set in and I started including CRC32 in the filenames as well. When a file compares bad, I can re-check it's CRC32 multiple times from the server and it is always wrong. Last night for example 2 out of about 300 files that I moved had bad CRC. I copied both of the bad copies back to my machine and compared them using HxD file compare to the source local files. In both cases, a single bit was toggled wrong in a random place within the file. This happens when running normal with a parity drive, out of curiosity, I moved a ton of files with no parity drive in place and still had the problem occur, albeit the files moved a lot quicker. Interestingly, if I grab all the files that I have tagged with a CRC32 in the filename and read them back from unRAID, always check out ok, if the file copies correctly, it seems to stay good on the server. Now before I include logs and specs, this has been happening since my first unRAID server, and I have replaced my server board/case/cooling/cables/memory/cpu three times since I first bought a key some 4 years ago and have experienced it from version 4.x until the last version 5. I had always attributed it to maybe a dodgy network card and resigned myself to always performing writes to the array using a write/test approach. I now want to get to the bottom of it because this has persisted through different motherboards, PSU, hard drives that were 1TB and 1.5TB that are now all 2, 3 and 4TB drives. I thought it may have something to do with drives spinning up/down as it would seem that when I browsed to a new share, the current copy would pause for a number of seconds (I assume while a drive spun up) and sometimes that file would end up being corrupt, but I couldn't reproduce it often. So - I can't afford to keep my drives spinning at all times to avoid the problem, any suggestions? One thing that is common to my servers is the adaptec 1430 4 port sata cards. As a test, all the files that had successfully copied, I have for the last two nights just been reading all files sequentially that have a CRC32 in the filename and not a single error reading these files that were successfully copied. At my wits end. I thought ethernet did CRC32 on each packet, is it possible unRAID is not checking the packets at all? Even the gigabit switch has been changed out for a different model.

Thanks very much!

I have one disk that has show some errors (read, not write) and they are slowly going up. All my disks are currently the same size and I would rather put a larger one in place of the suspect disk. If I remove the suspect disk, put in the larger disk, does anyone have first hand experience of if UNraid will move parity first to the new disk, and then use the old parity disk to rebuild the missing disk? I'm reticent to replace the parity disk first in case I get another read error on my suspect one when it goes to rebuild it, but at the same time I don't want to buy a smaller size drive to replace the current suspect one without needing to move parity. Could anyone give me some advise?

I'm using 5.0 beta 2 and my Popcorn Hour C200 just can't seem to connect over NFS like it used to with 4.5.6. I removed and re-added the shares but it never finds them. I can browse on the network and it fines my unRAID and then the shares are visible but no further. How did you get on with your TVIX 6500 with the new beta? Does anyone else have a PCH and unRAID 5.0b2 using NFS ?

Well, for what it's worth I thought I should post the motherboard model that I've had the trouble with. Gigabyte GA-EP45-DS4P rev 1.0 I've resigned myself for now (till the next beta, it may be fixed in the next kernel apparently) that it will be for archive only (never had problem putting files to it, probably because with parity happening its capped at 15MB/sec) and built another unRAID box using a Gigabyte GA-G31M-ES2L (also realtek NIC !). With this second box I've had no problems with 4.5b6 at all moving large files to / from with no kernel errors in syslog.

Ok so you have the same NIC chipset on your board. There are a number of boards in the HCL with specifically this Realtek 8111C chipset that don't mention any issues. Perhaps they were tested prior to the 4.5 beta 6 version unRAID. Can anyone confirm not seeing these NETDEV WATCHDOG: eth0 (r8169): transmit timed out in syslog using a Realtek 8111C NIC and advise what version unRAID they are running?

I think the r8169 driver supports multiple types of realtek NICs looking in dmesg with "dmesg | grep eth" on console mine appears to be eth0: RTL8168c/8111c at 0xf8254000, 00:1f:d0:23:06:bc, XID 3c4000c0 IRQ 27 what sort is yours?

Thanks for that. I was thinking of getting one of the motherboards in the unRAID HCL so as I can lose the videocard as well. If I do change motherboard and all the disks are added to a new controller, will the unRAID not start when it sees the world is quite different? I'll obviously know where to map each physical drive to unRAID drive (parity, disk1-5) but don't want it to start 'fixing' things in the way it first detects...

My motherboard has a onboard nic that uses the r8169 driver. I get occasional problems with the network going away and coming back: Jul 3 23:08:03 Tower kernel: r8169: eth0: link up Jul 3 23:08:57 Tower kernel: r8169: eth0: link up Jul 3 23:11:39 Tower kernel: r8169: eth0: link up Jul 3 23:12:14 Tower in.telnetd[2006]: connect from 192.168.0.15 (192.168.0.15) Jul 3 23:12:33 Tower login[2007]: ROOT LOGIN on `pts/1' from `192.168.0.15' Jul 3 23:21:34 Tower emhttp: shcmd (80): /usr/sbin/hdparm -y /dev/sdc >/dev/null Jul 3 23:27:21 Tower kernel: r8169: eth0: link up Jul 3 23:29:04 Tower in.telnetd[2026]: connect from 192.168.0.15 (192.168.0.15) Jul 3 23:29:15 Tower login[2027]: ROOT LOGIN on `pts/2' from `192.168.0.15' Jul 3 23:31:34 Tower emhttp: shcmd (81): /usr/sbin/hdparm -y /dev/sdg >/dev/null Jul 3 23:31:35 Tower emhttp: shcmd (82): /usr/sbin/hdparm -y /dev/sda >/dev/null Jul 3 23:31:45 Tower emhttp: shcmd (83): /usr/sbin/hdparm -y /dev/sdd >/dev/null Jul 3 23:31:46 Tower emhttp: shcmd (84): /usr/sbin/hdparm -y /dev/sde >/dev/null Jul 3 23:39:48 Tower emhttp: shcmd (85): /usr/sbin/hdparm -y /dev/sdf >/dev/null Jul 3 23:49:11 Tower emhttp: shcmd (86): /usr/sbin/hdparm -y /dev/sdg >/dev/null Jul 3 23:53:02 Tower kernel: r8169: eth0: link up Jul 3 23:53:38 Tower last message repeated 2 times Jul 3 23:56:32 Tower last message repeated 2 times Jul 3 23:58:26 Tower last message repeated 2 times Jul 3 23:59:56 Tower kernel: r8169: eth0: link up The switch is solid, the cable is good and this server has been rock solid in its life before unRAID. Doing some googling I did find a interesting post in a linux kernel bug thing Maybe I'm barking up the wrong tree but could their be a problem with the current version of the driver that's causing this? Current kernel says it is a 2.6.29 version. Putting files on I never had any trouble (probably because the throughput was always 10-14MB/s where as pulling files off it gets around 60MB/s at least until it starts having issues and the eth0 goes away and comes back. attached my dmesg and syslog