Write error on storage pool Error 0x800705AA Insufficeint resources exist to complete the requested

danivtec

Using the last 2 builds I have started getting an error when transferring files to my server via copy and paste. The error server service records:

Write failure on storage pool
VAILSERVER 20/06/2011 17:46
There was an error writing to a drive on the pool.
To see which files were affected and try and resolve this problem:
1. Open the Dashboard.
2. Click StableBit DrivePool.
3. Select the Hard Drive Pooling tab.
4. Select the Unhealthy drive and click the repair task on the right.

 

The error code is 0x800705AA Insufficeint resources exist to complete the requested service.

 

If I use Richcopy to transfer the files I get no error.

 

EDIT: I am now getting this error with Richcopy

 

Can anyone help?

logs http://www.mediafire.com/?je8sfihe6cnjjfb

danivtec

Going back to build 1836 resolves this error

Alex

I've seen this error reported several times, but I can never get a good trace of it.

It would be very useful to get a full log collected, including the kernel log.

Follow these instructions:

http://wiki.covecube.com/StableBit_DrivePool_Log_Collection

(this is different than what you've posted above)

It it extremely important to flip off the logging switch shortly after the error occurs and to zip up the logs before re-enabling logging.

The kernel log is a 100MB rolling log that will overwrite itself in a few minutes.

danivtec

Upgraded to latest build again and reproduced problem first time.

 

Logs here http://www.mediafire.com/?4rnol2uvxj2cyic

Alex

This error points to a handle leak. I don't see any while trying to reproduce this over here with 1856.

Can you grab procexp from http://technet.microsoft.com/en-us/sysinternals/bb896653

Start it up on the server and expose the Handle count column (right click on columns, under Process Performance, select Handle count)

Now, what's the highest handle count that you have?

On my server it's svchost.exe with 1,387. Make sure that you don't have any process using too many handles.

----

The write error is coming from Windows when DrivePool is writing a file. This is different from when there is an error being returned from DrivePool because some reason or other.

Is it possible that the drive is actually failing?

danivtec

http://imageshack.us/photo/my-images/26/unledqm.png/

 

Just to reconfirm that if I go back to build 1836 I dont get this error?

WillCS

I'm getting this same error on the current build(1864), I only started using DrivePool a couple days ago, the previous build I don't believe I had a problem with but if I did it was maybe once now it's happening all the time.  It doesn't happen with all files and the type of file doesn't seem to matter either. I don't believe my drives are failing as it's been copying to different drives and still happens. 
I downloaded procexp as well and my highest handle count is 1,301 for lsass.exe.
Other things I notice is memory consumption, when not doing anything it's around 25-20% used then when starting the file copy it's starts growing to 75-80% when transfering a single file and then starts dropping back down to the 35-40% range and then i get the 0x800705AA error.

danivtec

Can you upload you logs

Alex

Alright, since this is still happening in 1864 then the issue is not resolved yet.

Doesn't look like it's the handles.

All the logs point to the error coming from Windows when DrivePool tries to access the pool parts.

I will keep looking.

Is it possible that a drive is running out of space?

M2 doesn't handle that very well, and there is no balancing in M2 so it's not easy to fix the issue. M3 will do better.

WillCS

Here are my logs
http://geekify.us/files/Service.zip
File space is not the issue, most but not all of the files it's happening on are 8GB+ and on all current drives in the pool have ~340GB free space.
Anything you'd like me to try or test, I'd be more than happy to help.

danivtec

Alex

 

I didnt get this in Build 1836 so the changes from then may indicate where the problem lies. I also notice that transfer speed is lower than before with bursts of speed to gigabit then drops down to 20 to 30% maximum speed on a gigabit network. Many times before the speed used to stay pretty constant maxing out my gigabit network.

Alex

I didnt get this in Build 1836

...

Yes, I will look at it again in more detail. This needs to be fixed, whatever it is. It's just a little hectic right now with M3 being put together.

Alex

Is this the error?

WillCS

Yes

Edit: Just went and copied some files just to make sure.  The only difference for me is instead of move file mine says copy file.  Also, not sure if where the original file matters but I'm getting it while I transfer my old v1 files over via a external hard drive usb3 connection.

danivtec

Yes here aswell

Alex

Ok, so we're on the same page now.

The fix for this didn't make it into build 1914, but I will look into it for the next build.

danivtec

What was the fix?

Alex

No fix yet. I meant that it was reproduced artificially and will be looked at for the next build. Probably tomorrow.

Just shuffling around priorities.

Alex

Build 1919 is out and addresses this issue.

Let me know if it fixes it.

Alex

@WillCS:

You have a 4.8 GB metadata file in the store. That is not normal.

The file is located in /Service/Store in your zip.

You should delete it and restart the StableBit DrivePool service (or reboot the server).

Your pooled data will not be affected. You might have to run the Foreign disk wizard if it's a disk metadata file, which is what it looks like it used to be before it got mangled.

WillCS

Thanks for letting me know, I deleted it and went through the wizard and updated to 1919.  I'm gonna copy some data while I sleep, I'll report back tomorrow.

WillCS

I've transferred ~1TB so far and no errors, looks like this is fixed for me.  Thanks

danivtec

Fixed here aswell. Speeds are very up and down though as before.

griffo

I'm getting this error when copying large files (eg 4Gb) to my Drivepool shares. I understood this was fixed sometime ago in a previous build. I am using the latest available build.

Any clues? Is anyone else having this problem?