I have the latested RC5 installed and did not notice on the 4.7 but everytime I am writing to the array and if i delete a file while the writing is taking place the delete function takes an extremely long time and the writing function fails and the shares take a few minutes to come back. i have a cache drive installed and I am deleting file from the user shared folder. the logs do not show anything going on and after a reboot yesterday i tried again between 1-1:30pm while copying a 30gig file and deleting a 40gig file. what could be causing this?

 

thanks

James

syslog_7-5-2012.zip

By any chance how many files are in the folder you are a writing to and b deleteing from??

just one per movie folder.

Can you duplicate the problem when making sure none of the drives are sleeping?

 

Can you duplicate the problem without the plugins? Just RC5.

This has happened for me on every build of unRAID for the last 2 years, are you positive it's RC5 only?

 

Dealing with 30+GB files, unRAID doesn't like deleting them while doing something else. I assume it's never been fixed/improved because hardly anyone has files as big as us.

This has happened for me on every build of unRAID for the last 2 years, are you positive it's RC5 only?

 

Dealing with 30+GB files, unRAID doesn't like deleting them while doing something else. I assume it's never been fixed/improved because hardly anyone has files as big as us.

 

Do you have iso's in separate folders ie one folder per iso or all your isos in one folder??

Those of us coming from the Windows world are used to seeing any deletions be very fast, and completely irregardless of the file size.  In the DOS and Windows worlds (FAT, FAT32, and NTFS), a deletion is just a modification of the file entry, plus a release of the cluster chain.  However, ReiserFS is a somewhat different file system underneath, and takes *much* longer to perform deletions, an amount of time proportional to the size of the file.  And it can appear to be a relatively CPU-intensive operation.  ReiserFS has other very nice advantages, so deletion time is just a tradeoff.

That explanation doesn't excuse unraid's lack of priority queuing, it should just slow down the transfers to allow the file system time to complete, while still servicing the incoming file write albeit at a snail's pace until the delete operation is complete. I've noticed the same behavior on 4.7, where a windows file transfer times out when the array is too busy. I've learned to work around it, but it shouldn't happen. I expect multiple file operations to run to completion, with the understanding that queuing up a load of operations will cause slowdowns. Timing out and failing the transfer shouldn't happen unless the server is locked up or unable to process the data at all, which shouldn't happen if the incoming data is throttled back. I'll readily admit I don't know how or even if a fix can be implemented, I just don't think it should be acceptable behavior. 

This has happened for me on every build of unRAID for the last 2 years, are you positive it's RC5 only?

 

Dealing with 30+GB files, unRAID doesn't like deleting them while doing something else. I assume it's never been fixed/improved because hardly anyone has files as big as us.

 

Do you have iso's in separate folders ie one folder per iso or all your isos in one folder??

 

I've used both over the years, and both have this issue.

The problem may likely be on the Windows side as it only uses a single samba connection for all operations. There is nothing unRAID can do when it's the client side that is broken.

Open up a couple telnet sessions using MC and perform file operations on both and see what happens. I've learned to only do one operation at a time when using my unraid box.

Open up a couple telnet sessions using MC and perform file operations on both and see what happens. I've learned to only do one operation at a time when using my unraid box.

I've done this before from IPMI with two console instances but I make sure that I'm coping to and from separate disks.  When I tried coping from the SAME disk but to 2 different disks I had problems.