Okay, this has been really annoying to me.

 

SITUATION:

 

After filling up any individual drive to capacity, then deleting files to free up space, whenever I try to again fill that drive up to near maximum capacity, I always get error messages somewhere along the process and the transfer fails.

 

There is clearly enough free space, as in one case, I freed up 22GB then started to transfer a 12GB file, but it will always fail.

 

It doesn't matter which of the 8 data drives I've tried it on (which are all WD -EARS 2TB drives).  It doesn't matter where I try to place the new files, either at the root, or nested in some other folder(s).  I've tried both "moving" and "copying" files.  I've tried transferring files from another drive in the unRAID.  I tried transferring the source file to a different unRAID drive with PLENTY of space as well as to another non-unRAID drive and it succeeds so its not some corruption issue with the source file.

 

Sometimes it MIGHT work if I reboot the server; but not always.

 

I get no errors when I'm filling up the drive for the first time to maximum capacity; it's only after I reached capacity then delete files does the error occur when I attempt to transfer more files into the freed space.

 

This is under OS X (10.6.4).  I haven't tried under Windows (XP or 7) as my files are on Mac formatted drives.

 

I can only successfully transfer files repeatedly that are significantly smaller than the available free space (e.g. 5GB file works for a 22GB free space).

 

I've attached the syslog, though there are no errors or entries regarding the file transfer.

---

PS: The error code I always get is -51, FWIW.

syslog.txt

Can you show us the output of the

df

command.

(It shows the free space on the disks)

I'm getting something similar with my WD-EARS 2TB drive which is close to full.

 

It's disk1 in my case (74GB available):

Filesystem            Size  Used Avail Use% Mounted on
/dev/sde1             3.8G   56M  3.7G   2% /boot
/dev/md2              1.4T  1.3T   86G  94% /mnt/disk2
/dev/md3              932G  853G   79G  92% /mnt/disk3
shfs                  4.1T  3.9T  239G  95% /mnt/user
/dev/md1              1.9T  1.8T   74G  97% /mnt/disk1

 

Trying to copy a ~5GB file I get "The handle is invalid" and sometimes XP will give "delayed write failed" errors.

 

I see nothing in the syslog and have run a parity check (no errors) and reiserfsck on the disk (again, no errors):

Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
   Leaves 462016
   Internal nodes 2745
   Directories 39
   Other files 707
   Data block pointers 467516222 (0 of them are zero)
   Safe links 0
###########
reiserfsck finished at Wed Sep 15 00:16:30 2010

 

I just tried copying a file again and it failed - even though no file activity is taking place I now see unraidd is taking up ~95% cpu and mdrecoveryd is taking up ~26% cpu

syslog.txt

I've tried transferring files from another drive in the unRAID.

When you tried this did you telnet into the Unraid server and use the cp command between disks? I just tried this and this method worked for me while copying from a smb share failed.

 

Sometimes it MIGHT work if I reboot the server; but not always.

Same here....

 

When you get the problem, if you telnet into the Unraid server and run top, do you see the process unraidd maxing out a CPU?  I just did a reboot and upon restart unraidd is immediately maxing out a CPU again... I guess I'll leave it overnight to see what happens.  No clues in the syslog.

OK - it's performing a Parity check which explains the activity.  Not sure why though, as I didn't initiate it.

 

Just trying to figure out if we've got the same issue here....

Can you show us the output of the

df

command.

(It shows the free space on the disks)

 

I'm having problems (still) adding a new drive and after 48+ hours, I'm running the preclear_disk script a SECOND time, but with the -n switch.  If I EVER get past the "clearing" issues and can finally regain access to the unRAID via the command prompt, I will let you know the results of the df command, though I will state that the web GUI shows PLENTY of space and is what I was using to report my situation.  if the web GUI uses a different method than the df command for space calculations, I am certainly interested in how it performs it...

Can you show us the output of the

df

command.

(It shows the free space on the disks)

 

After getting the error trying to move a 6GB folder to a drive with 18+GB free, I went to the console and issued the df command.  The free space on the drive in question corresponds to the web GUI, and is thus:

Filesystem     1K-blocks    Used         Available  Use%  Mounted on
/dev/md5       1953454928   15307692572  18888040   100%  /mnt/disk5

 

I rebooted and lo, in this case I was able to successfully move the 6GB after I moved it from another drive in the array to my Mac before the reboot, then to the target drive after the reboot.

 

So I proceeded to fill the remaining free space of 14466324 and was again successful when copying files from my Mac startup volume, inching to just 662.9MB free.

 

But as I said, sometimes rebooting unRAID works.  Sometimes it doesn't.  The fact is I shouldn't HAVE to reboot the server for this period.  I shouldn't be getting any errors when there is clearly enough free space as shown in the web GUI.

I've experienced this on nearly full drives from time to time as well. Before transferring something over I make sure the parity and destination drives are awake by creating then deleting an empty file/folder on the drive I plan to copy to. I then use TeraCopy to transfer the file. I also have it to automatically perform an MD5 check to verify integrity. This sequence seems to lesson the occasional transfer problems I've experienced.

Another drive, another error.  Rebooting does not resolve it.  But attempting a second time did from first failure after reboot worked.

 

Weird.