In this NetApp training tutorial, you’ll learn about LUN space reclamation, which is a way that we can make sure that the amount of space used in our LUNs is reported correctly on the ONTAP system. Scroll down for the video and also text tutorial.
NetApp LUN Space Reclamation Video Tutorial
Mark Paniwozik
This course is great. I’m only half-way through it and have learned loads of new information. Highly recommended course if looking to learn about NetApp. Neil uses real world applicable scenarios and information to teach the curriculum and it’s great being able to follow along on a virtualized lab built out on my laptop.
LUN Space Utilization Reporting
With our SAN protocols, the hosts manage the file system on their LUNs. This is different from the NAS protocols of NFS and CIFS wherein the storage system manages the file system.
With NAS we've got file-level access, but with SAN, the clients have got block-level access. They connect to their LUN, they format it with a file system, and it's the hosts themselves that are directly managing the file system.
As a result, the host and the storage may report the used space differently because the storage system does not have the same kind of visibility into the file system.
In the figure below, the big box is a LUN. For example, the client writes two files to the LUN, File 1 and File 2. Each consumes 25% of the LUN space. The client will report 50% space used in the LUN and the storage will also report 50% space used. The client has written blocks to the LUN which take up 50% of the size.
Then, the client writes a third file, File 3, to the LUN. This also consumes 25% of the LUN space. Now, the client reports 75% used, and the storage system also reports 75% space used.
So you're maybe thinking, "Okay Neil, I can't see any problem there," but now we start to get into the problem. Next, the client deletes File 1 and File 2. The client doesn't actually send any notification to the storage system by default.
It just knows itself that those blocks are no longer in use and it's able to write new data to those blocks. It doesn't do anything to physically delete the blocks on the storage system.
The client reports 25% space used because it knows that the 50% is available again. However, the storage system still reports 75% space used because 75% has been written to the LUN, and the storage system does not know about anything different happening. It doesn't know that 50% of that is now free and available again.
Then, the client writes a fourth file, File 4, to the LUN. This is also consuming 25% of the LUN space. Now, the client correctly reports 50% space used because the client, of course, has got full visibility. The storage system reports 100% space used since it doesn't know about the free space.
If the client deletes File 4, the client reports 25% space used. Again, the storage system doesn't know about this happening, so the storage still reports 100% space used. Once the client has written data that is equivalent to 100% of the LUN, the storage system always sees the LUN as being 100% full.
In our example again, the client writes File 5. The client always reports correctly, it sees 50% space used, and the storage system is always going to see 100% used from this point on.
If we looked at an actual storage utilization tool on the client, the disc defragmentation tool on a Windows client for example, you can see that it can see the files that are taking up contiguous space. It includes fragmented files, unmovable files, and free space. The storage system does not have this kind of visibility into the file systems though.
The used capacity never decreases from the storage system perspective. It's always going to only increase up to 100% and then it's going to stay there. Most hosts will end up appearing to use all of the space of the LUN from the storage system's perspective.
The used space is reported incorrectly on the storage system. At this point, the host will still be able to write to the LUN. When it writes to the LUN, the storage system will just see that as being an overwrite.
Even though the storage system sees the LUN as 100% full, it's going to still allow overwrites. Therefore, the client can still write to that LUN. You will not be able to realize any space efficiency savings from thin provisioning though, because the storage system always sees the LUN as being 100% full.
Thin provisioning is not going to work since it doesn't see any free space. So, it's going to work the same as if you thick provisioned it.
Space Reclamation
We can fix this problem by using space reclamation. Space reclamation reclaims space automatically when your host deletes data. The way it works is that the host will signal to the storage system, telling the storage system that those blocks are freed up now.
The storage system will see that now as free space so it can reduce the size of the used space when you're using thin provisioning.
There’s a signal from the storage system to the client going back in the other direction. The storage system will notify the host when the LUN cannot accept writes due to the lack of space at the volume level.
If the volume gets full, the storage system will tell the client that it can't accept any new writes. It then makes the LUN read-only, rather than taking it offline.
The client won't be able to make any writes but at least the client can still see the LUN. It can still do reads from it and it's still online. Obviously, that's a lot better than the LUN going completely offline and the client having no access to it at all.
The way that you enable space reclamation is at the command line. You use the command:
lun modify -vserver name -volume name -lun name -space-allocation enabled
You would need to specify your volume and your LUN, then, you enable space allocation. This is configured at the LUN level.
Before you do this, you must verify that the client operating system does support SCSI thin provisioning. It is needed to be supported on the client for this to work. It can cause problems if the client does not support it, therefore, space allocation is disabled by default.
You must take the LUN offline to change the setting. If the client operating system does support this, then you should enable it before you connect the client to the LUN. If you forget to do that, you're going to have to take the LUN offline to change the setting and that's going to cause an outage.
Additional Resources
Space Reclamation: https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-A926B796-9C0D-4935-A84A-D9BF291487A4.html
How host operating systems can automatically reclaim space and keep LUNs online: https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-93D78975-6911-4EF5-BA4E-80E64B922D09.html
Click Here to get my 'NetApp ONTAP 9 Storage Complete' training course.
Libby Teofilo
Text by Libby Teofilo, Technical Writer at www.flackbox.com
With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.