Determine root volume/aggr from cache?

[abrian]

Is there any way to determine the root volume or aggregate from information in the WFA cache?

Thanks!

Brian

[tanzim]

Hi Brian,

Yes, it is possible to determine the root volume or aggregate information from the WFA cache.

However,could you elaborate on the use case so i could better understand it and suggest an appropriate way to access the required information.

Are you looking to access the root volume/aggregate information of the vserver(Cluster Mode) or vfiler(7 Mode)?

Regards,

Tanzim

[abrian]

Hi Tanzim,

Thanks for responding!  The customer wants to make sure no allocations happen in the root aggregate, which is not always called ‘aggr0’.  I was hoping to determine the root aggregate directly, or as the containing aggregate of the root volume.   They want to select the aggregate as a parameter, so this would need to be a Query parameter type based on selected Array, with the root aggr excluded from the list.

Thanks!

Brian

[tanzim]

Hi Brian,

I think i misread your requirement the first time around.You are looking to find the system root aggregate and volume as opposed to the vfiler root aggregate/volume(my silly assumption). I stand corrected in my previous answer and would have to say no.

However, if OnCommand monitors whether the aggregate is root (zapi supports it), a custom dictionary entry can be created in WFA to cache this attribute(root/non-root) of the aggregate following which a user-input query can then be written.

I can provide this information to you by tomorrow.

Regards,

Tanzim

[abrian]

Yes, that's correct, I need to know the root aggr (e.g. aggr0 on most controllers), not the root of a vFiler.

I figured it would require a schema enhancement with script acquisition.  I'm still learning that, so I look forward to any examples you come up with.  It's not a high priority at the moment, so don't interrupt anything important.

Thanks!

Brian

[shailaja]

Hi Brian,

Could you try the following query on your system and see if it helps.

SELECT array.name AS array, volume.name AS root_volume_name, aggregate.name AS aggregate_of_root_volume

FROM

storage.array array,

storage.volume volume,

storage.aggregate AGGREGATE,

storage.vfiler vfiler

WHERE           vfiler.array_id = array.id

AND          vfiler.name = 'vfiler0'                           -- Indicates that this is the hosting storage system

AND          vfiler.root_volume_id = volume.id

AND          aggregate.id = volume.aggregate_id

The result in my system looks something like:

Thanks,

Shailaja

[abrian]

Hi Shailaja,

That query works great!  I'm surprised it works for controllers not licensed for multistore, but it does!

Thanks, that really helps!

Brian

[abrian]

Hi Shailaja,

It looks like I spoke too soon.  I've got a strange situation where the incorrect volume is being listed for vfiler0.  It's actually a volume that was owned by another vfiler that is now gone (and thus the volume is now owned by vfiler0).   It may have been the root volume of the vfiler before it was destroyed, but I'm not sure (it was for vfiler snapmirror work some time ago).

I'll send you details separately, in case you'd like to take a look.

Thanks!

Brian

[shailaja]

Hi,

The scenario you mentioned might be an issue on OCUM/DFM side.

Anyway, let me take a quick look at your setup.

Thanks,

Shailaja

[abrian]

Since we have determined that the workaround using the vfiler table is unreliable (due to DFM database problems), can I request an enhancement to include root volume information in the cache?  I'm not sure whether the root volume indication is best as a property of array, or as an "is-root" property on volume, but I suspect either would work fine.  It might also be useful to indicate the root aggregate (in either the array or aggregate table) as well, since the primary reason workflows would want this information is to exclude root aggrs that aren't named aggr0.

Thanks!

Brian