SnapDrive 6.1 "not designated for thin provisioning"

[philipmidcalf]

Hi

I can not find any reference to this message. I know it is only classed as “info” but the message suggest something is miss-configured.

filer104> Sat Oct 31 19:27:05 GMT [app.log.info:info]: WIN2003-SNAPDRI: SnapDrive 6.1: (373) Service execution status: Found non-space reserved LUN(s) on volume '/vol/win2003_sd_01'. This volume is not designated for thin provisioning.

The volume on the filer has a guarantee of “none” and the LUN does not have space reserve enabled (by using storacl.exe).

Thanks

Philip

[watan]

Hi Phillip,

There may be an issue with the sdparams.conf file . Please have a look at the following KB and TR.

https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb47898

http://media.netapp.com/documents/tr-3483.pdf  <- check out section 7.3 which talks about the sdparams.conf file.

[philipmidcalf]

It has taken me a while to get back to testing this but I have and I cannot see why the message is being produced and I am thinking it is a bug.

Using SD6.1 and 7.3.1 Sim (although I originally saw the issue on a live 7.3.1 filer) I can create the "This volume is not designated for thin provisioning" message when both the LUN has its Space Reservation parameter set to "false" and the "ThinProvision.xml" file has the volume set with the space_reservation_new_lun parameter to “false” (set via the spacereserve set command it STORACL, and as per kb47898). When these two parameters are set (which they would be if you create a new LUN via SD once you have used STORACL to set spacereserve to false) and either you restart the server or just restart the SnapDrive service the filer reports the "This volume is not designated for thin provisioning" message in the console. It does not seem to matter how the volume is set up, fat, thin, autosize enabled etc just the aforementioned two parameters.

I did check the tr-3483.pdf and specifically section 7.3 but as I expected the "sdparams.conf" file is now superseded by the STORACL command and therefore the values in the “sdparams.conf” file have no barring.

Therefore I think it is a bug that the message is created as I believe both the LUNs and volumes are setup correctly, Watan could you pass this onto the SnapDrive development team?

Thanks

Philip

[watan]

Hi Phillip,

Can you get me a OntapwinDC for this node?  It will probably be after the New year to get this looked at by the dev team.

Thanks,

Allan

[philipmidcalf]

Sure, please find attached, the time to look at is the messages from 26th December and not the messages from the 29th December. I will PM you the password.

Thanks

Philip

[watan]

Hi Philip,

I was able to confirm with the engineering team that they are aware of this issue.  They have linked this issue with another burt 313750 and will work to get this resolved in a patch or the next release.  This will be decided in the weeks to come.

[mheimberg]

Hi

Actually we are encountering the same message.

We are using Ontap 7.3.3P5 and SD 6.2P1.

Configuration is:

volume guarentee volume, fractional reserve 0, snap reserve 0, snap sched 0, snap autodelete on, vol autosize on, lun space reservation disabled.

Unfortunately the BURT seems not to be public, so all I get is "bug information not available".

Has nothing happened regarding this issue? Or could you tell which combination of settings and options triggers this error?

Regards

Markus

[watan]

Hi Markus,

The burt that I originally mentioned has been fixed in the newer releases and your version should be ok.  Can you try the following from STORACL?

STORACL> spacereserve get -vol "volname" 

[philipmidcalf]

FYI, I have tried this again using SnapDrive 6.3 and I no longer get the message so it is certainly fixed in 6.3.

Philip