Is there any way to check used data size within a LUN

[mahala]

Something wrong here either SACORP or my pc that my description doesn't appears.
Thats why trying to attach txt file if works.

[reide]

You can also use ONTAPI to get this information.  The API call "lun-get-occupied-size" will tell you how many bytes have been written to a NetApp LUN on a controller.  It is my understanding that this command only shows what has been written to the LUN on the active file system and does not include bytes consumed by snapshots or fractional reserve.   Output is similar to the following:

<results status="passed">
        <occupied-size>948350976</occupied-size>
</results>

lun-get-occupied-size

[top]

Get the size occupied by the LUN in the active FS.

Input Name	Range	Type	Description
path		string	Path of the LUN.
Output Name	Range	Type	Description
occupied-size	0..2^64-1	integer	Size occupied by the LUN in the Active FS in bytes.

Errno	Description
EINVALIDINPUTERROR
EONTAPI_ENOMEM
EVDISK_ERROR_NO_SUCH_VDISK
EONTAPI_ESTALE

Vfiler-enabled

Yes

NOTE:  It is very important that the user understands what this number represents. A LUN can contain many more bytes of data than the host file system (on top of the LUN) shows due to file addition/modification/deletion.  Unless you're using something like space reclamation, the LUN has no idea when files are deleted, so it keeps those blocks. Over time, all LUNs - Netapp or otherwise - fill-up close to 100% with blocks because the LUN isn't aware of what has been deleted from the file system.   TR-3483 "Thin Provisionin in a NetApp SAN" does a great job of explaining this.

[mwilliamsm]

Hope this directs you to the right path!

In VMware you use the vCenter/Virtual Center Storage to see the available lun size.  On Windows you use My Computer or Explorer.   Etcetera.  Check your Host.

The should know your aggr available size df -A -g because the luns are gauranteed by volume or file....  Etcetera.  Staying on track - the next should know the volume size df -g /vol/volname were the luns file resides. 

[alexandernow]

- Using Client based tools:
The  most effective method of viewing LUN consumption from the client  perspective is to use client-side tools such as Windows Explorer or UNIX  'du'.
Windows Disk Management can also be used to show the LUN size.
 
- Using Filer storage based tools:
If LUN is already in use and data has been written to the LUN:
Create a new volume, create a new LUN, and ndmp copy the old LUN data to the new LUN , and df -r.

Using the methods above will show the exact size of the consumed LUN space.

NOTE: The df -r command will effectively display the consumed LUN space as long as the following are true.
    a. There is only 1 LUN within the volume.
    b. There are no snapshots of the LUN within the volume.
    c. Space reservations are turned off on the LUN.
        Space reservations and Fractional reserve will affect the usage displayed.

LUN size displayed on the filer via df -r and client utilities may differ in size.

There are two distinctions in the way LUN space consumed can be viewed:

  1. LUN Space can be viewed as Filer Storage Blocks consumed within the WAFL volume.
      Due to the way some operating systems format the LUN, the filer will see the LUN as a sparse file.

  2. LUN Space can be viewed as the amount of space consumed by the Client Operating System within the LUN.
      This view displays the Operating System's view of amount of space consumed and LUN size.
      Client operating systems may have data written to blocks within the LUN that is not actual user data.

[chriskranz]

Another solution is to cheat!

If you are taking snapshots, then fractional reservation is your key. Or you could create a temporary snapshot just to get the frac-res reading.

If you are not taking snapshots then you could drop the volume space reservation to none, and the used space should equate to the used space within a LUN.

But yes, you are correct, the filer does know the used space within the LUN, however you don't get the ability to interogate this.

I'll have a tinker on some of my test systems and see if there is a better way.

[anthonyfeigl]

Hey Raju,

Some stuff on fractional reserve.

http://communities.netapp.com/groups/chris-kranz-hardware-pro/blog/2009/03/05/fractional-reservation--lun-overwrite

Hope it helps.

Anthony Feigl

[mahala]

Very nice explnation on fractional reserve but my question is bit different and this question arises due to this fractional reserve only.

As ONTAP is able to find out used block within a LUN and also able to find out changed block then why there is no command to tell used data size within the LUN.

I am looking for some way at filer side to find out LUN usage because as I am not aware of that so always need to go to server where LUN is presented and to see the usage of LUN.

I feel if ONTAP is able to find out used/changed block within a LUN, based on that ONTAP reserves overwrite space, then there should be some command or way to find out LUN usage from filer side itself.

What do you say about that ?

Regards,

Raju

[madden]

>>I am looking for some way at filer side to find out LUN usage because as I am not aware of that so always need to go to server where LUN is presented and to see the usage of LUN.

Broadly NO, but in some cases (although unsupported), YES.

I say broadly NO because a LUN is simply a container holding bytes written by a host.  That host could have created multiple partitions on a LUN and formatted these with various filesystem types, it could have concatenated the LUN with some other LUNs and striped partitions and filesystems across it, etc.  Data ONTAP can't unravel the relationships that exist, "crack" the filesystem type to determine freespace, and then display this back to the user very easily.

I say in some cases YES because Data ONTAP does have a diag level command that can show df output (by reading the superblock) for UFS and VxFS filesystems that exist on a LUN:

fas001*> lun df
usage:
lun df  <lun_path> [ -v ]
   decode contents of lun.
   -v gives more details about the lun.
   NOTE:
       Currently only UFS and VxFS file systems can be detected

Hope that helps.

[anthonyfeigl]

Raju,

I have no experience with LUNs on NetApp (only other SAN Vendor equipment), so unfortunately I am not sure.

I will dig around to see if I can find an answer.

Anthony