Subscribe

Anyway to use 'Read-NaDirectory' recursively ?

I am trying to write a PowerShell script to return the size of a directory which includes all files and subfolder (recursive).

The native PowerShell CmdLet 'Get-Childitem' has an optional parameter called -Recurse which does this for me.

Is there a similar function (or a different CmdLet) to let me do this or do I have to write my own routine to do this (which I believe will be a lot slower)?

If there is now way to do this with the current CmdLet, can I submit a feature request for a future update to the toolkit?

Thanks very much,

- Bill

Re: Anyway to use 'Read-NaDirectory' recursively ?

Hi, Bill.  You may be able to use the PS Provider in the Toolkit to recurse, but it uses Read-NaDirectory (which isn't recursive) underneath, so it may be simpler to code but probably won't be any faster.

PS C:\> Connect-NaController dunn

Name                 Address           Ontapi   Version

----                 -------           ------   -------

dunn                 10.61.167.60      1.14     NetApp Release 7.3.5: Mon Nov 22 21:32:44 PST 2010

PS C:\> Mount-NaController

Name           Used (GB)     Free (GB) Provider      Root

----           ---------     --------- --------      ----

dunn                                   DataONTAP     /

PS C:\> cd dunn:

PS dunn:\> dir /etc -Recurse

Name                                     Type            Size      Created     Modified Owner Group   Perm Empty

----                                     ----            ----      -------     -------- ----- -----   ---- -----

.                                        directory      12 KB    8/12/2008     8/3/2012     0     0   1070 False

..                                       directory       4 KB    8/12/2008     2/2/2012     0     0   1077 False

.avail                                   file          904 B     8/13/2008     8/3/2012     0     0   1070

.zapi                                    directory       4 KB    8/13/2008     8/3/2012     0     0   1070 False

acpp_fw                                  directory       4 KB    2/11/2010    2/14/2011     0     0    700 False

asup_content.conf                        file           17 KB    2/14/2011    2/14/2011     0     0   1070

asuptriggers.sample                      file            6 KB    2/14/2011    2/14/2011     0     0   1070

boot                                     directory       4 KB    8/13/2008    2/14/2011     0     0    700 False

cifs_homedir.bak                         file          810 B      4/5/2010     4/5/2010     0     0   1070

cifs_homedir.cfg                         file          827 B      4/5/2010     4/5/2010     0     0   1070

cifs_nbalias.bak                         file          600 B      4/5/2010     4/5/2010     0     0   1070

Re: Anyway to use 'Read-NaDirectory' recursively ?

Wow!  Thanks for the quick reply!

I had already written a vbScript to do this but it has two major problems.  It is very slow (we have a lot of files/folders to traverse).  It constantly produces errors due to Windows File System length limitations.  These results in an inaccurate file size total.

I was hoping to use the NetApp APIs to circumvent both of these issues.

Even when I manually recurse using the Read-NaDirectory CmdLet, it is very slow.

Do you think this could be an enhancement for a future release of the OnTap PS Toolkit?

Re: Anyway to use 'Read-NaDirectory' recursively ?

The API that Read-NaDirectory uses doesn't support recursion, so making the cmdlet do that won't speed things up.  As I mentioned, the provider can support recursion.  Please note that the file APIs are many times slower than normal in-band I/O like CIFS or iSCSI, so you're probably better off using standard Windows file APIs to traverse the directory structure if you can make those work for you.

Re: Anyway to use 'Read-NaDirectory' recursively ?

Ok, I understand.  I guess I'll have to keep using my current vbScript which uses CIFS to access the data.

I was hoping that there would be something with OnTap/WAFL that could use the processor of the filer to do the calculation but I guess it is not in the design.

Thanks again for such a quick response to my inquiry.  I really appreciate your time and I love the toolkit.