topic Device Busy Error Mounting VSC backup in VMware Solutions Discussions

Device Busy Error Mounting VSC backup

nicholsongc — Wed, 04 Jun 2025 15:08:32 GMT

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

Jeff_Yao — Tue, 16 May 2017 05:02:47 GMT

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

Re: Device Busy Error Mounting VSC backup

nicholsongc — Tue, 16 May 2017 13:19:50 GMT

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.