Subscribe
Accepted Solution

Device Busy Error Mounting VSC backup

I have a case opened but I want to run this past the community.

 

 

When I attempt to mount a VSC backup of a volume containing five (5) LUNs the process fails with an error like this:

 

Mon Apr 24 14:26:57 EDT [NETAPPNODE01: api_dpool_09: wafl.sis.clone.create.failed:info]: File clone create of file /vol/Documents_vol/.snapshot/smvi_Documents_novmsnap_20170310210101//Docs03_LUN in volume Documents_vol failed with error: Device busy..

 

I can then see the next messages entries where the LUNs that could be created are deleted and the process STOPS with no visual error in the GUI.

 

This is likely related to BURT 835630 (http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=835630)

 

I am able to manually clone (file) the LUNs using the file clone create command switch -bypass-throttle true but that defeats the purpose of using VSC to mount/unmount my backups for restore operations.

 

Has anyone hit this problem before and what was the permanent fix for it???

 

 

Re: Device Busy Error Mounting VSC backup

if that's burt you're hitting, it looks like u need to upgrade ur data ontap?

Cannot find the answer you need?  No need to open a support case - just CHAT and we’ll handle it for you.

Re: Device Busy Error Mounting VSC backup

From the NetApp TSE who worked the case:

 

I was able to work with one of our CORE EE’s yesterday afternoon.  We confirmed that you are running into http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=835630.

 

Here is the rub…this clone-create backpressure is expected behavior.  ONTAP is going to throttle the number of concurrent clone create operations in order to ensure that we don’t impact the node the volume resides on. 

 

I found out that it isn’t so much the number of concurrent clones.  It’s actually a calculation ONTAP does to determine a “maximum split backlog”.  So ONTAP basically computes what it would take to sustain a certain level of split throughput for 24 hours.  It looks like the ONTAP developers tuned this “maximum split backlog” in ONTAP 9.0.  So you might find that ONTAP 9.0 is a bit more forgiving before enacting clone split back pressure limits.