montery

I'm trying to use TightVNC (installed as a viewer on my Windows 7 machine) to connect with an Unraid 6-rc3 Ubuntu VM. I can ping from windows to the Ubuntu VM, no problem. I can ping from Ubuntu VM to Windows, no problem. According to the URL the built-in VNC viewer on the Unraid weg-gui is saying, the host is the ip address of the Unraid server, and the port is 5700. Ubuntu VM has a different IP. Any attempt to connect to the VM IP or Unraid IP on port 5700 yields a error message "No connection could be made because the target machine actively refused it" Should I be using a different port? Not sure if I should be tweaking the XML file for the VM? I just accepted the templated defaults when I set it up. Any ideas? Thanks in advance!

Thanks DaleWilliams, I have attached a syslog. And Smart Status report. syslog-2014-03-15.txt SMART-Drive_0.txt

Hi everyone, I had a disk die on me, and am currently rebuilding it. I happen to glance at the syslog to see how things were going, when I noticed a whack of these types of error messages: Mar 14 04:33:20 Tower kernel: md: disk0 read error, sector=641936912 (Errors) Mar 14 04:33:20 Tower kernel: md: multiple disk errors, sector=641936912 (Errors) Mar 14 04:33:20 Tower kernel: md: disk0 read error, sector=641936920 (Errors) Mar 14 04:33:20 Tower kernel: md: multiple disk errors, sector=641936920 (Errors) Disk0 is my parity drive. My conclusion is that the parity drive is suffering from read errors in restoring my data. Indeed if I look closer at the main screen, it says right there: 46 read errors. Questions: How badly should I worry about the integrity of my (restored) data? What actions should I take to mitigate the errors from the drive? Should I assume the worst and immediately replace the drive? Thanks so much in advance!

Thanks Peter!! That totally fixed the problem. Case sensitivity... "D'oh!"

Thanks, I'm following your suggestion and moving everything to off of disk4 that I don't want there. I'm also doing some house cleaning to make sure that the other drives don't have extraneous backup or download directories that could confuse the mover. Now, some house cleaning and then we'll move some more files over and see what happens.

Hey guys, sorry to hijack the thread, but I had the same issue. If I read this correctly, it was on Disk 0 -- my parity drive! Should I run a parity check or just ignore it? Nov 21 19:32:55 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:32:55 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:32:55 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:32:55 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:32:55 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:32:55 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:32:55 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:32:55 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:32:56 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) (Drive related) Nov 21 19:32:56 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:32:56 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:32:58 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:32:58 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:32:58 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:32:58 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:32:58 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:32:58 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:32:58 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:32:58 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:32:59 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) (Drive related) Nov 21 19:32:59 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:32:59 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:33:01 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:33:01 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:33:01 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:33:01 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:33:01 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:33:01 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:33:01 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:33:01 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:33:02 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) (Drive related) Nov 21 19:33:02 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:33:02 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:33:04 Tower kernel: ata4: limiting SATA link speed to 1.5 Gbps (Drive related) Nov 21 19:33:04 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:33:04 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:33:04 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:33:04 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:33:04 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:33:04 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:33:04 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:33:04 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:33:05 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) (Drive related) Nov 21 19:33:05 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:33:05 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:33:08 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:33:08 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:33:08 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:33:08 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:33:08 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:33:08 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:33:08 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:33:08 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:33:08 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) (Drive related) Nov 21 19:33:08 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:33:08 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:33:11 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 (Errors) Nov 21 19:33:11 Tower kernel: ata4.00: port_status 0x20280000 (Drive related) Nov 21 19:33:11 Tower kernel: ata4.00: failed command: READ DMA EXT (Minor Issues) Nov 21 19:33:11 Tower kernel: ata4.00: cmd 25/00:f8:ff:8a:6d/00:03:87:00:00/e0 tag 0 dma 520192 in (Drive related) Nov 21 19:33:11 Tower kernel: res 51/40:c7:20:8e:6d/40:00:87:00:00/e0 Emask 0xb (HSM violation) (Errors) Nov 21 19:33:11 Tower kernel: ata4.00: status: { DRDY ERR } (Drive related) Nov 21 19:33:11 Tower kernel: ata4.00: error: { UNC } (Errors) Nov 21 19:33:11 Tower kernel: ata4: hard resetting link (Minor Issues) Nov 21 19:33:11 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310) (Drive related) Nov 21 19:33:11 Tower kernel: ata4.00: configured for UDMA/133 (Drive related) Nov 21 19:33:11 Tower kernel: sd 3:0:0:0: [sdd] Unhandled sense code (Drive related) Nov 21 19:33:11 Tower kernel: sd 3:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 (System) Nov 21 19:33:11 Tower kernel: sd 3:0:0:0: [sdd] Sense Key : 0x3 [current] [descriptor] (Drive related) Nov 21 19:33:11 Tower kernel: Descriptor sense data with sense descriptors (in hex): Nov 21 19:33:11 Tower kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Nov 21 19:33:11 Tower kernel: 87 6d 8e 20 Nov 21 19:33:11 Tower kernel: sd 3:0:0:0: [sdd] ASC=0x11 ASCQ=0x4 (Drive related) Nov 21 19:33:11 Tower kernel: sd 3:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 87 6d 8a ff 00 03 f8 00 (Drive related) Nov 21 19:33:11 Tower kernel: end_request: I/O error, dev sdd, sector 2272103968 (Errors) Nov 21 19:33:11 Tower kernel: ata4: EH complete (Drive related) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103904/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103912/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103920/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103928/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103936/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103944/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103952/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103960/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103968/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103976/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103984/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272103992/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104000/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104008/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104016/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104024/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104032/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104040/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104048/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104056/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104064/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104072/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104080/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104088/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104096/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104104/0, count: 1 (Errors) Nov 21 19:33:11 Tower kernel: md: disk0 read error (Errors) Nov 21 19:33:11 Tower kernel: handle_stripe read error: 2272104112/0, count: 1 (Errors) Nov 21 19:48:16 Tower kernel: mdcmd (54): spindown 8 (Routine) Nov 21 20:33:47 Tower kernel: mdcmd (55): spindown 7 (Routine) Nov 21 20:46:58 Tower kernel: mdcmd (56): spindown 0 (Routine) Nov 21 20:46:59 Tower kernel: mdcmd (57): spindown 4 (Routine)

Hi folks, running Unraid 4.7 here, and have 8 data disks not including parity & cache. I've a fairly simple directory structure like this: TV \Series \Season \Episodes Movies \Movie Backups \Computer \<backup files> Music \Audio Disks \HD Audio \Stereo Downloads I want my backups to go to one drive only, and never spread across drives. The rest can smear across drives as they like. So, here's how I've set up my user shares: Share Name Backups Downloads Movies Music TV Allocation Method: Most-Free High-Water Fill-Up High-water Fill-up Min. Free Space: 10000000 500000 16000000 4000 2000000 Split Level: 1 <blank> 2 <blank> 4 Included disk(s) Disk4 Disk4 <blank> <blank> <blank> Excluded disk(s) <blank> <blank> Disk4 Disk4 Disk4 Use cache disk: No Yes Yes Yes Yes Export (SMB): Export read/write Export read/write Export read/write Export read/write Export read/write Export (NFS): <blank> <blank> <blank> <blank> <blank> Here's the problem: Disk 4 has 204 blocks free now, and backups are spilling over to other drives (Disk3, Disk5 and Disk7 so far). There are Movies, Music, and TV folders in Disk 4 even though I've explicitly excluded those folders from disk 4. Windows backup is complaining that the 'drive is full'. I've seen other people scratch their heads on this one, so now I'm wondering if this is a bug, or is it more a case of user-error? Any suggestions how I can configure shares to keep the other stuff off Disk 4, and leave Disk 4 to only Backups and Downloads? I purposely kept it simple so that I could trouble shoot, but yikes, this should not be this hard!

Woops! I had fumbled around and started a parity re-build when the new drives where installed prior to getting the preclear started. I think my parity is pretty much requiring a full rebuild now. And performance is never sufficient! Although realistically I've got 8 5400 rpm drives (or better) SATA II drives hanging off two PCI SATA cards, I'm not sure how much more performance I can squeeze out of this beast. But, that's a topic for another thread. Thanks again Joe!

Thanks Joe... follow-up question on Parity drive, if I may. Parity is a WD20EARS drive, jumperless, and was installed factory fresh into the array. Did not preclear it prior to activating it as the parity drive. Now that I'm adding 2 more jumperless WD20EARS drives, which are being precleared with the -A option as I write this, I have to rebuild my parity. Should I take this opportunity and change the parity drive to be 4K aligned, or just leave well enough alone?

I have a older drive (circa 2007?) 320Gig SATA drive, that I was using as a data drive but have now switch it out, pre-cleared it, and am running it as a cache drive now. I'm running Unraid 4.7 pro. When I started the pre-clear, I specified the -a option to have it align at sector 63. It successfully completed the pre-clear with no errors. Now it's formatted and everything 'looks' good. The thing that is bothering me is that when I first ran the preclear, it thought by default to align at sector 64. Based on everything I've been reading, I think I should be okay to use this cache drive now. But am I?

Thanks Lionelhutz... In the end I managed to get all the data off the drive. I've now gone out and bought four 2TB WD20EARS drives, and I now have a long weekend to build a new parity drive and migrate data to the new drives. 2tb drives are awfully big aren't they? Takes 12 hours just to build a parity drive?! Yikes.

Still struggling to recover data off HDB. I can only interact with unraid through a telnet session. Right now the data pull off the failing drive is averaging about 2.2MB/s. That's really slow and I'm starting to think maybe the parity drive is at risk? I did a top command and I see the top 2 activities are unraidd and mc. I'm using mc to manually move files off HDB so that I can at least keep track of what it's doing. I did try the the nohup mv /mnt/disk2 /mnt/disk7 & trick last night, but it stopped transferring files at around 2am last night. Here's hoping this type of rescue operation works!

I was performing a parity check in 4.7 pro and I saw this in the syslog: Jul 25 18:24:36 Tower kernel: handle_stripe write error: 22259944/2, count: 1 Jul 25 18:24:36 Tower kernel: md: disk2 write error Jul 25 18:24:36 Tower kernel: handle_stripe write error: 22259952/2, count: 1 Jul 25 18:24:36 Tower kernel: md: disk2 write error Jul 25 18:24:36 Tower kernel: handle_stripe write error: 22259960/2, count: 1 Jul 25 18:24:36 Tower kernel: md: disk2 write error Jul 25 18:24:36 Tower kernel: handle_stripe write error: 22259968/2, count: 1 Jul 25 18:24:46 Tower kernel: hdb: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error } Jul 25 18:24:46 Tower kernel: hdb: status error: error=0x7f { DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, LBAsect=140183580147464, sector=18446744073709551615 Jul 25 18:24:46 Tower kernel: hdb: possibly failed opcode: 0x50 Jul 25 18:24:46 Tower kernel: hdb: drive not ready for command Jul 25 18:24:46 Tower kernel: hdb: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error } Jul 25 18:24:46 Tower kernel: hdb: status error: error=0x7f { DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, LBAsect=140183580147464, sector=18446744073709551615 Jul 25 18:24:46 Tower kernel: hdb: possibly failed opcode: 0x50 Jul 25 18:24:46 Tower kernel: hdb: drive not ready for command Jul 25 18:30:01 Tower kernel: hdb: irq timeout: status=0xd0 { Busy } Jul 25 18:30:01 Tower kernel: hdb: possibly failed opcode: 0xb0 Jul 25 18:30:01 Tower kernel: hdb: status timeout: status=0xd0 { Busy } Jul 25 18:30:01 Tower kernel: hdb: possibly failed opcode: 0xb0 Jul 25 18:30:01 Tower kernel: hdb: drive not ready for command Jul 25 18:30:01 Tower emhttp: disk_temperature: ATTR_Temperature_Celsius not found Unraid stopped doing anything and I clicked the "stop" button to take the array off-line. Now I'm being told to wait and I can't connect to the Webgui and its not responsive to anything. But I can still telnet into the box. Not sure what next steps to take. Ultimately, I have a spare drive that I can move files onto, but it's already in the array and formatted, so I don't think I can count on the parity drive to recover to it. And I don't think I have another old IDE of the same size I can stick in there. Any suggestions? I've attached the output of my smartctl -a -d ata /dev/hdb command (rpt1) and smartctl -a -d ata /dev/hdb as rpt2. I've followed the instructions on http://www.lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems and reiserfsck returned no errors. I couldn't powerdown cleanly so I hit the big red switch and upon reboot it immediately found 14 sync errors and is happily checking the remainder of all the disks. So after reboot, unraid ran the parity check again. And again there's some sort of error on my HDB disk. I think I'll see if I can move stuff from HDB to one of the other drives and then eventually replace that drive. unraid_smartctl-rpt1.txt unraid_smartctl-rpt2.txt

Sorry, don't mean to hijack a thread here, but how about moving files from your inbound box (the computer that you use to get your source files) to your Unraid server? I use Azereus and I can move files from one directory to another after the download is complete, but I'm trying to think of a way to have them moved over to the server after the upload ratio has returned to 1. Any ideas? Or should I wait for the version of unraid that includes file management under the covers? Thanks.

Ummm..... yes, it's redundant. Parchive works by taking a file (or series of files) and chunking it up into smaller pieces. Then it calculates parity data across those pieces and stores this data in separate files. On the internet, there used to be a popular method of transferring files around back in the mid-90's using the newsgroups (check out google newsgroups for a sample of what's there). People would UUencode their files, send them as messages to the newsgroup, and other people would pull these messages down, knit together the messages, and voila! Software! Or, in the case of the newsgroups, typically it was porn, but whatever. There was a slight problem to this otherwise efficient approach. The underlying architecture of the newsgroup meant that files (spread across many messages) are sent on a store-and-forward basis by individual computers that participated in the newsgroups. Because of this store-and-forward method of spreading the goodness, not every system had the same amount of drive space to dedicate to the newsgroups. So old messages didn't stay long, and in some cases, if disk space was low, admin's would not do the "forward" part of store and forward. The end result was that you would see missing parts out of a multi-part series. How does Parchive solve this? If you lost a part of your data you could recover so long as you had the parity files. Depending on how much of the archive you've already downloaded, you may not need all of the parity files. It's pretty cool software and I was initially toying with the idea of using Parchive instead of Raid-5. Then I found unraid. Unraid works on the same principle as Parchive -- in fact, I would be surprised if it didn't use the same mathematical algorithm to compute the parity bits (google Reed-Solomon). Unraid takes your data on all your drives, and breaks it logically into chunks. Each chunk is then (essentially) added up to a binary 1 or 0 value. The parity bit is also added so that all the data across all the chunks is the same (either all zeros or all ones). This parity info is then written to the parity drive, and consulted on read from the data drive (to ensure accuracy) and re-calculated on writes. So, Parchive isn't buying you anything since unRAID does it for you!

i like the idea of a kick-ass unRaid server... so, as a thought experiment, I tried to come up with the fastest server I could! Here's what I came up with: 1) Use a server class motherboard. None of this wimpy PCI interface nonsense, go big or go home with PCI-X! When you are doing a parity build, you are reading from all of your data drives and writing to your parity drive at the same time. All that data is streaming off your hard drives, through the PCI bus, into the CPU, back out of the CPU, back down the PCI bus and onto your parity drive. With PCI, there is not enough bandwidth to handle the quantity of data your hard drives are capable of pushing up to the CPU... therefore, make this bottleneck go away with a larger bus architecture. This'll take a bite out of those really long parity synch times. 2) Next, lets cut down on how much time it takes to move files from other computers on the network. Gigabit is nice, but lets move the data. How about a pair of gigabit ethernet cards channel-bonded so that you have two gigabits worth of bandwidth available for you to upload with? Oh, don't forget, you'll need to do the same on your inbound system. 3) Moving now into more exotic options for speed... this would need a software change in unraid before it becomes really feasible. String a bunch of 10K RPM hard drives together as your parity drive. This would also reduce your parity build and parity write times significantly! Too bad there aren't any 700Gig 10K rpm hard drives around, so you will need to string a bunch together. Oh, and probably need to use a raid-5 approach on the parity drive array so that you don't risk your data should you lose a single parity drive. 4) This one is more towards up-time than pure performance, but if your system isn't up, you can't use it, so it counts. Get redundant on the power supplies baby! Hot swap power supplies -- should you lose one, it fails over to the second, and you can then pull the dead one and replace it. Ideally, you plug each power supply into totally separate circuits in your house. Most serious server installations plug into separate circuits in the city grid, crazy, I know!! But hey, we are talking about "overkill"!! 5) Use ECC memory! Typically a little slower than your regular ram, but this is a server and I want reliability! If some little bit in one of those memory chips suddenly decides it will never be anything other than what it is at the moment forever more, I want the ECC there to save me. 6) Of course, ECC may fail too. Prevent that with redundant, hot-swap memory. If a whole bank of memory fails, swap out to the auxiliary bank!! No down time if you have this feature! In case you think I'm pulling your leg here with these features, I'm not. Serious sever class hardware have these features (and a few others I didn't mention). You are only thinking along one axis of performance. Don't forget uptime/reliability count towards performance as well. As Tom (and others) have said a few times here in the forums, buy quality. In all honesty, worrying about RAM speed and CPU speed is a waste of time. Worry about throughput -- eliminate bottlenecks and where you will spend most of your time waiting. If you spent $200 more on a faster CPU, you would never notice it if you've stuck it behind a 100mbit network card, right?

Stuck at the VI stage? Best google on how to use VI. It's not the most intuitive text editor. The basic commands that I remember are: <i> to go into insert text mode <esc> to go into command mode <:w> to write a the modified file <:q> to quit vi You will need to go into command mode before executing any commands (like write or quit). You will need to go into the insert text mode to add text and use the backspace key to fix typo's. There are LOTS more powerful commands -- use google to learn them. But this is the Coles notes that got me through VI.

Actually, I did some quick googling around to see if slackware has any issues with the onboard nic, and sure enough, there were mentions of issues/difficulties, etc. I could have gotten it to work with some tinkering, but hey, a new Intel Gigabit NIC is less than the cost of 4 premium pints of beer, so I figured it's more fun to pick one up and install known good hardware and then spend time drinking than to spend time beating my linux noobness into the ground!! (hey, I know where my priorities are!) Anyhow, the end result is fantastic. I can watch HD Planet Earth without a single dropped frame (>16000 bytes/sec at times!) and the low-bitrate video no problem. I will now spend the rest of the weekend enjoying Unraid Goodnesstm Thanks Tom, great product!

Update - I tested sending files from my current player system over to unraid - speed was 480MB/sec over standard 100mb Ethernet. After playing around with configurations in SAMBA and VLC player, I managed to get VLC to not be choppy... but I had to set the cache to 3 seconds, which means any activity (fast forward, pause, stop, etc) in VLC would not occur until 3 seconds later. Wow, talk about jet lag! I wasn't happy with that solution. Why would VLC be so choppy? It had to be a separate problem, not related to software. I started to think maybe it was a router/network wiring issue. Ugh! So I checked my settings in my DI-524 router... nothing there to cause suspicions. Hmmm.... Wait! I've never actually performed a speed test going the other way -- FROM unraid to my player without using VLC. What would happen if I just copied a file off the server? Sure, seems like an idea any idiot would test first, but nooo, not me... I'm thinking "media server, fill 'er up and forget about it." Why would I ever want to pull files DOWN from a media server?? Do'h! I rebooted Unraid (to clear out any changes I made to SAMBA) and started fresh. 1) Upload 1 GB VOB file. Speed on average: 480 MB/sec 2) Download same file. Speed on average.... dunno, never let it finished, but I would guesstimate 1 MB/sec Hardware problem!! Or Unraid software problem... dunno yet. I am using a SOHO Ethernet card on my motherboard, but the motherboard has onboard RealTek RTL8139 LAN chipset. Next test: 1) Shutdown Unraid 2) Configure bios to use onboard LAN 3) Start Unraid 4) perform ifconfig to see if onboard LAN is recognized. Appears so. 5) ping from player pc -- no connection. Hmm... after doublechecking and rebooting to make sure I configured the BIOS properly, I'm stuck. I can't ping from Unraid to outside world, yet the router link light is on indicating the port is at least getting power. Alright, I am too much of a LINUX noob to do this the unix way, so I'll put my WinXP HD back into the unraid box, and do it from Windows. Upon boot up, Windows see's both network cards. Ok, no hardware problems so far. Switch the ethernet to the plugin lan card, and start testing: 1) Upload 1 gig VOB file. Fine, 480MB/sec speed. 2) Download same file. Same as before, ~ 1MB/sec speed maybe...dunno, never let it finish. 3) Switch cable to onboard LAN 4) Download same file. Excellent! 560MB/sec speed. I'm assuming the current build of Unraid does not support a RealTek 8139 NIC. If it had, it should have shown up as Eth0 device, and the SOHO card as a Eth1 device. No biggie either way, as I'm off to pick up a intel NIC. Of course, this doesn't resolve the VLC issue, but at least I know now it's a hardware problem!

I know this is a old topic, but I would like to re-open it because I'm suffering from movies stuttering when playing them over the network. First, some steps leading up to the problem: 1) After first boot, test watching some low-bit rate1 video using VLC. Everything is awsome! Yay! 2) Watch a high-bit rate2 video using VLC. As expected, on a 100mb network, some dropout occurs. 3) Leave Unraid on over night... 4) Move files more files over, perform some additional tests on low-bit rate video using VLC. Eh? What's this? Stuttering?? Now the steps I've taken to try to isolate: 1) First, open up VLC and keep an eye on the statistics and messages from the debug log. 2) Executing a file results in dropped packets (according to the VLC statistics) and plenty of warnings about my player PC being too slow. (Note: Never any issues playing low/high bitrate video on local or Highspeed USB external drives). 3) Re-execute same tests, this time keep an eye on Network traffic. Network traffic is very low -- less than 5% bandwidth consumed. 4) Perform ifconfig eth0 on Unraid box, confirmed no data packets lost or retransmitted. 5) Suspect low-ram may be issue. (256MB of ram in Unraid server). So I leave it alone until I get more ram. Upgraded to 512 and re-ran my tests: 1) First, open up VLC and keep an eye on the statistics and messages from the debug log. 2) Test watching some low-bit rate video using VLC. Everything is awsome! Yay! Problem solved! 3) Move files more files over, perform some additional tests on low-bit rate video using VLC. Eh? What's this? Stuttering?? Conclusions 1) Rebooting Unraid seems to clear the problem for a short time may be a hint that it's a Unraid memory allocation issue. I'm discounting this because I've tested both 256 and 512MB memory configurations. 2) May very well be a VLC issue with a possible SAMBA tweak needed (See this post:http://new-forum.videolan.org/viewtopic.php?f=12&t=11854&st=0&sk=t&sd=a&sid=b18912c95453bd008d3a96bc0da5bc8a&start=30#p66283. I'll try the SAMBA tweak (if I can figure out how -- too much of a Linux Noob!) 3) Reading through the rest of this particular thread indicates that VLC does LOTS of "tiny" reads. So I'll try a different player (sigh, I like not having to play the "hunt the codec" game!). Tweaking the buffer size didn't improve things at all. 4) May be an issue with network configuration or network/pc hardware. I'll let people know how my testing progresses... but if anyone can provide additional testing scenarios or recommendations on where else to look for problems, that would be greatly appreciated. Thanks! 1Low-bit rate I've defined as anything that uses on average less than 1000 mbits/sec (as measured by VLC) 2High-bit rate I've defined as anything that uses on average more than 1000 mbits/sec (as measured by VLC)

I saw on the Hardware Compatibility http://www.lime-technology.com/wordpress/?page_id=17 page that the Silicon Image SATA is untested... Not anymore! Just in case anyone else had any concerns around the SiL3114 chipset, I have two of these in my FIC AM37 motherboard (with a paltry 256 MB of ram...but hey, it's working!) and UnRAID see all drives plugged in to the two SATA adapters. Everything appears to be working perfectly with the 3 drives that I've assigned to the server.

I have a slightly different question... how do I find out what the GUID is from within Windows XP? In reading the instructions: It's not immediately clear to me if these are instructions for people who have already installed the free edition of Unraid, or if you can do this from within any browser on any OS. Anyways, I tried poking around the device manager from within Windows, but couldn't get the information (or my USB drive doesn't have a serial number... can't tell!!). Any know of a little app that'll read the GUID from within Windows?

... since I last visited the unRaid site. But I have to say that I'm very pleased to see two things: SATA support "Free" version of the software SATA support is important because we have all been wanting spindown capability across all our drives. Don't know if unRaid supports SATA fully or not, but at least I can now play with it on a test box. Thanks lime-technology! I've been extremely interested in this software since it was first announced on AVS forum, and have been following it with keen interest ever since. I'm looking forward to trying out the "free" version!