unable to delete phantom qtree from onCommand System Manager (3.1.2)

[ntorvik]

I was doing some testing with 7MTT and needed to abort and reset the enviroment  between my 7mode and cDot systems (both lab systems).

When going into the qtree section of my SVM I see two qtrees (image attached).  That don't belong to any volumes.  I had already deleted the volumes from OSM.   So when logging in via the CLI I executed a qtree show and saw that the qtree's (the ones listed as LAB_CIFS_7MTT)  were not present.

But when I executed a vol show command I could see the volumes that were previously deleted with OSM?   What exactly is going on here?  Bug??  (image attached).

I was able to offline and delete the volumes (again!) thankfully.  But I am wondering why OSM appeared to do the work but actually didn't.

Thanks...

[aborzenkov]

Which version of cDOT? In 8.3 volumes are not deleted immediately, but put into delete queue and finally destroyed after 12 hours (I think this is default period). This gives you chance to undo accidental volume deletion.

[ntorvik · Accepted solution]

I was using onTap 8.3.2.     If that is indeed the behavor then that would explain the lag in the volume deletes.    Although, it doesn't explain why the old Qtree's were still behing displayed in  OSM, but not the CLI.    

But I think I have a work around.    I ran through the entire transition again with my small 5GB volume.  And when I was finished, and I strated clearing it off my cDOT system.  This time Instead I deleted the Qtree's first, then the shares/exports, and last the volume.   Deleting the volume last ensured there were no artifacts left in OSM.     Also, this time when executing 'qtree show' and 'vol show' everything showed as being deleted.

I know there are dependencies in place to prevent a person from deleting a volume in OSM that has active shares/exports.   But they should probably put one in place for Qtree's as well.