May 25, 200818 yr I recently replaced a 640GB drive with a 1TB drive on my server. The 640GB drive was the current drive being written to in my "movies" share set to "high-water." I had only used about 200GB of this hard drives space and have plenty of room left to go until I hit the mark where unRAID will switch to another disk. About half way through on a file I'm transferring (22.8GB) the transfer fails. Using Windows Vista I'm getting an error saying "Unable to locate MyMovieName.iso" and it gives me the option to cancel or re-try. I tried "retry" but that does nothing. I have also tried ripping directly to the unRAID server using two different programs. One of the programs was reporting a disk full error and the other program just ended with no explanation. Interestingly, I can write the file to the server if I don't use the share and instead write directly to the disk the share is writing to. It would appear that after upgrading a disk unRAID has some sort of bug with regards to shares. I've though about using the "restore" option which would rebuild parity and record the new disks... but is there another option? Is this in fact a bug? Syslog is attached. This log as after a reboot. I tried transfering "BLADE_RUNNER.ISO" the first time using windows vista to the share. The second transfer was also from windows vista but this time directly to the disk.
May 25, 200818 yr I recently replaced a 640GB drive with a 1TB drive on my server. The 640GB drive was the current drive being written to in my "movies" share set to "high-water." I had only used about 200GB of this hard drives space and have plenty of room left to go until I hit the mark where unRAID will switch to another disk. About half way through on a file I'm transferring (22.8GB) the transfer fails. Using Windows Vista I'm getting an error saying "Unable to locate MyMovieName.iso" and it gives me the option to cancel or re-try. I tried "retry" but that does nothing. I have also tried ripping directly to the unRAID server using two different programs. One of the programs was reporting a disk full error and the other program just ended with no explanation. Interestingly, I can write the file to the server if I don't use the share and instead write directly to the disk the share is writing to. It would appear that after upgrading a disk unRAID has some sort of bug with regards to shares. I've though about using the "restore" option which would rebuild parity and record the new disks... but is there another option? Is this in fact a bug? Syslog is attached. This log as after a reboot. I tried transfering "BLADE_RUNNER.ISO" the first time using windows vista to the share. The second transfer was also from windows vista but this time directly to the disk. The issue you are describing has nothing to do with the the configuration of the disks, or the parity drive, so unless you really want to wait for parity to be rebuilt, and then still have the problem, do not use the "restore" button. Instead, it sounds as if you might have some issue with the file system on one or more of your data disks. I don't see anything in your syslog that looks out of the ordinary. It appears to know the correct size for all your disks. May 25 13:41:50 NAS kernel: md1: running, size: 732573496 blocks May 25 13:41:50 NAS kernel: md2: running, size: 976762552 blocks May 25 13:41:50 NAS kernel: md3: running, size: 625130776 blocks May 25 13:41:50 NAS kernel: md4: running, size: 312571192 blocks May 25 13:41:50 NAS kernel: md5: running, size: 732574552 blocks Your best bet is to run reiserfsck on each of the /dev/md? devices to be certain their file systems do not have any corruption. The procedure to do this is described here: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems Has SP1 been applied to your copy of Vista? If not, it is something you should plan on. Vista has so many bugs... It might easily be the reason the transfer fails part way. I know that "windows" in general is very poor at reporting exactly why failures occur. To it, everything might be reported as "out of space" The only time you need to use the "restore" button is when you are permanently removing a drive from your array and do not intend to replace it with another in the same slot. Only then do you need to save a new initial configuration and calculate parity from the currently assigned and working drives. Now, I'm not saying their can't be a bug in the user-file-system code. Not too many of us copy 50 Gig files from one machine to another, so it might be there on my system, but never occurs since the largest DVD ISO I have is under 10 Gig. First, let's figure out if the file-system is OK, then we can think of other possibilities. Next time a failure occurs, capture a syslog BEFORE you reboot. It may have a clue why the error occurred. Joe L.
May 25, 200818 yr Author File systems check out ok. I ran reiserfsck on all 5 of my data disks and no errors were found. I am running Vista SP1. I have been writing files of this size to the unRAID for the past couple of days and had no issues until I upgraded the 640GB disk to the 1TB disk. I can also write directly to the disk... just not to the share. Knowing these two things, it seems safe to say Vista has no problems writing to the unRAID server. The problem seems to be unRAID OS related as it's only a problem when it comes to writing to a share. I understand about the restore feature... it's generally not a good thing to use and it's poorly labeled (confusing). I was just thinking that unRAID itself may be "confused" after the disk upgrade and using the restore feature would wipe away any instance that the 1TB disk used to be a 640GB disk. So now that the file sysem check is ok, is there another test I can run on my end that can give more information? And that last syslog was before I rebooted. It contained 1 transfer that errord (writing to a share) and a second transfer that passed (writing directly to the disk).
May 25, 200818 yr The unRAID User Share system is built on top of the unRAID disk system, which includes the parity system, so 'Restoring' it or rebuilding parity would not have accomplished anything. Also, the unRAID system, including the Share system, is built fresh each time in RAM, so once it has built itself around the present drives, including your new terabyte drive, that 640MB is not even a memory, so I can't see any connection between it and your problem. As Joe says, the syslog is clean, and there is no indication that unRAID was aware of anything wrong at all. The unRAID disk system is well tested, and reliable, but the Share system was recently re-built, and is part of these beta releases, not a final release yet, so there could be an issue there. One of the problems reported is that the Split Level seems to default to 0 or blank, which can easily cause a Full Disk error, like the one you had. Make sure that your Split Level settings are 1 or higher. It is possible that is what caused at least part of the problem.
May 25, 200818 yr Author Thanks for the reply. It's good to know the "restore" option wouldn't do what I thought it may do... so the only time it's needed is when removing a disk that will not be replaced. My share I'm having trouble with is set to a split level of 2. So it sounds like this could be a share system error with the latest beta. I find it odd though that this problem happened only after upgrading a hard drive. I had originally been writing to disk1, then that met it's quota for "high-water" and switched to disk2. Disk2 had no problems writing to the share until I replaced that drive. I've been running 4.3b6 the entire time.
May 26, 200818 yr File systems check out ok. I ran reiserfsck on all 5 of my data disks and no errors were found. That is good, at least it is not the cause. I am running Vista SP1. I have been writing files of this size to the unRAID for the past couple of days and had no issues until I upgraded the 640GB disk to the 1TB disk. I can also write directly to the disk... just not to the share. Knowing these two things, it seems safe to say Vista has no problems writing to the unRAID server. The problem seems to be unRAID OS related as it's only a problem when it comes to writing to a share. I think you are right. Sure seems like it is a user-file-system related bug given those symptoms. I understand about the restore feature... it's generally not a good thing to use and it's poorly labeled (confusing). I was just thinking that unRAID itself may be "confused" after the disk upgrade and using the restore feature would wipe away any instance that the 1TB disk used to be a 640GB disk. So now that the file system check is ok, is there another test I can run on my end that can give more information? You can confirm the file system was created on the 1TB drive as expected. Type the following (I'm pretty sure your 1TB data disk is /dev/sde): fdisk -l /dev/sde It should show a single partition, using all the available blocks of disk space. And that last syslog was before I rebooted. It contained 1 transfer that errord (writing to a share) and a second transfer that passed (writing directly to the disk). I don't see any evidence in the syslog of the failure, but I'm pretty sure the syslog copy was made soon after a reboot. The log is from 13:41 (when you rebooted) through 13:55 (when you logged in). Hardly enough time to copy two large files. I'm not sure you attached the file you think you did. The last 4 lines in your log are as follows... nothing was logged between 13:41 and 13:55. May 25 13:41:52 NAS ifplugd(eth0)[1741]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. May 25 13:41:52 NAS ifplugd(eth0)[1741]: Program executed successfully. May 25 13:55:12 NAS in.telnetd[2000]: connect from 192.168.1.51 (192.168.1.51) May 25 13:55:13 NAS login[2001]: ROOT LOGIN on `pts/0' from `192.168.1.51' Joe L.
May 26, 200818 yr Author results from fdisk on my 1TB disk: NAS login: root Linux 2.6.24.4-unRAID. root@NAS:~# fdisk -l /dev/sde Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 1 heads, 63 sectors/track, 31008336 cylinders Units = cylinders of 63 * 512 = 32256 bytes Device Boot Start End Blocks Id System /dev/sde1 2 31008336 976762552+ 83 Linux Partition 1 does not end on cylinder boundary. root@NAS:~# root@NAS:~# That's odd about the syslog. Here's what I did... Booted the server tried to transfer a file from my PC to the unRAID share Transfer had an error and quite I logged in via telnet I created the syslog.txt file I stayed logged in via telnet I transfered the file again but this time to the actual disk (not a share) File transfer completed I created syslog2.txt via telnet I copied the file to my PC and uploaded here. I'm not sure why the times are so close together. The completed transfer took a little over 30 minutes... the one that failed took about 15-20.
May 26, 200818 yr Author I decided to try a transfer to a share on the unRAID server so I could post the exact error Windows is reporting. I've attached what I see once the transfer stops:
May 26, 200818 yr Author And here's the syslog since my last reboot (Since then I only tried to transfer this 1 file). Edit: Looking at it it doesn't look like anything about my file transfer was posted to the log. It shows all the boot up information and then my login via telnet... but nothing else.
May 26, 200818 yr And here's the syslog since my last reboot (Since then I only tried to transfer this 1 file). Edit: Looking at it it doesn't look like anything about my file transfer was posted to the log. It shows all the boot up information and then my login via telnet... but nothing else. The syslog shows no indication the network connection was lost, nor of any other issue. Normally I'd suspect the Vista PC next, or the cabling between it and your router, but you have consistent success in copying directly to the disk shares. With that in mind, we'll just have to wait for Tom to surface and take a look at this thread (he has not been active on the forum for about a week, so I expect his day job has taken his attention :'() Based on your tests, I also suspect an issue with the user-share file system. It might be difficult to duplicate on another system with a different mix of disks and free space, but in the interim, write directly to the disk shares. Joe L.
May 27, 200818 yr Author Just to update... I had been copying my DVD's to the unraid server via the share because I only seemed to have an issue with large files (blu-ray rips at 20+ gigs). Today copying over a 5 Gig movie via a share gave me the error I mentioned above. So it looks like I'm copying everything directly to disks until his share issue is worked out.
June 9, 200818 yr Author I have an old laptop with XP Pro on it... I'll try copying some movies to the shares via XP in the next couple of days and report if anything is different.
June 12, 200818 yr Hey LimeTech / Tom, I'm having a simiilar issue with 4.3 beta6. I can't try it with an earlier version, because with 4.2, my NIC doesn't have a working driver My symptoms are a little different: My client is OS 10.5 running on a Mac Mini. I am trying to transfer a lot of data from the mini to my UNRAID server over Gig-E, no jumbo frames, using a user share. I've tried using rsync and 'cp' from the command line, as well as a GUI file copy, and I seem to get the same behavior, which is that the copy works fine from anywhere from a few minutes to a few hours (there's LOTS of data), and then it errors out with an I/O error and aborts. The funny thing is that the mount doesn't go away, and if I just immediately restart the transfer, it starts right up again with noo complaints, but will have another error a bit later. This doesn't seem to be tied to any particular file or file size (happens on mp3's as wel as movies). Here is a sample of rsync showoing the error. The Rsync command I use is local -> local_mount --- so its still using the smb protocol to the unraid server. There doesn't seem to be anything useful at all in the unraid syslog or samba logs. rsync -avp /Volumes/backups/iTunes/ /Volumes/itunes . . . . rsync: write failed on "/Volumes/itunes/iTunes Music/TV Shows/24/01 6_00 A.M. - 7_00 A.M..m4v": Bad file descriptor (9) rsync error: error in file IO (code 11) at /SourceCache/rsync/rsync-30/rsync/receiver.c(312) iTunes Music/TV Shows/Jericho/ rsync: connection unexpectedly closed (2889392 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359) rsync: connection unexpectedly closed (94628 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-30/rsync/io.c(359) mini:Volumes eisner$ It's a Phenom Tri-core system, and I actually need to swap out the motherboaord with an Intel system anyway. I'll let you know if that makes a difference, but I don't see why it would matter.
June 13, 200818 yr So, I had been using a BIOSTAR A770 with a Phenom CPU. Yesterday I switched it out with an ABIT AB9 Pro and Core 2 Duo, and now everything seems to be fine. Same flash image, same disks, same cables, same case. Weird.
Archived
This topic is now archived and is closed to further replies.