Hello,
I am starting to thin provision LUNs (lun set reservation disable) in order to start using A-SIS on some large (1TB) volumes. Before I turn A-SIS on, I started testing these LUNs and do see the space on the filer grow accordingly with writes on the host. However, the space never seems to go down when I delete files on the host:
rtpstore2b> df /vol/iscsi Filesystem kbytes used avail capacity Mounted on /vol/iscsi/ 10485760 9974748 511012 95% /vol/iscsi/ /vol/iscsi/.snapshot 0 0 0 ---% /vol/iscsi/.snapshot
[root@vrhel5 /]# df /mnt/iscsi Filesystem 1K-blocks Used Available Use% Mounted on /dev/sde1 10321192 7804844 1992064 80% /mnt/iscsi
I see that when I begin writing again, the filer space won't start increasing until there is an increase in space above what the filter already thinks. Is this behavior normal? When I turn SIS on, will the filer LUN size reduce as blocks are deduplicated so that I can then reduce the volume?
Lastly, I will definitely need to know when my volumes autosize so I can focus my attention on not having the aggregate fill up. It would be wonderful if I could set up an SNMP trap to send to Nagios for notification. Before I dig into the MIBs and create the custom trap (if I even can), has anyone done anything similar they could share?
TIA,
Daniel
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
After a couple of replies, I have determined that the volume never decreasing is indeed normal behavior. I started SIS on the volume and the LUN did decrease, with great results.
Now if I can just configure SNMP notification for volume autosize events....
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Daniel Keisling Sent: Friday, January 25, 2008 12:07 PM To: toasters@mathworks.com Subject: Thin provisioning LUNs, A-SIS, and notifications
Hello,
I am starting to thin provision LUNs (lun set reservation disable) in order to start using A-SIS on some large (1TB) volumes. Before I turn A-SIS on, I started testing these LUNs and do see the space on the filer grow accordingly with writes on the host. However, the space never seems to go down when I delete files on the host:
rtpstore2b> df /vol/iscsi Filesystem kbytes used avail capacity Mounted on /vol/iscsi/ 10485760 9974748 511012 95% /vol/iscsi/ /vol/iscsi/.snapshot 0 0 0 ---% /vol/iscsi/.snapshot
[root@vrhel5 /]# df /mnt/iscsi Filesystem 1K-blocks Used Available Use% Mounted on /dev/sde1 10321192 7804844 1992064 80% /mnt/iscsi
I see that when I begin writing again, the filer space won't start increasing until there is an increase in space above what the filter already thinks. Is this behavior normal? When I turn SIS on, will the filer LUN size reduce as blocks are deduplicated so that I can then reduce the volume?
Lastly, I will definitely need to know when my volumes autosize so I can focus my attention on not having the aggregate fill up. It would be wonderful if I could set up an SNMP trap to send to Nagios for notification. Before I dig into the MIBs and create the custom trap (if I even can), has anyone done anything similar they could share?
TIA,
Daniel
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
This is idd normal behaviour. When blocks are getting filled up in your lun, Netapp will also notice that and the used space will grow. When however your file system frees blocks, this is not told to Netapp, so those blocks will be kept in use even when there is no data in it anymore. Netapp simply doesn't know they are freed.
In Windows you can use Snapdrive 5 with a new feature called 'Space reclamation". In this case Snapdrive will scan your NTFS filesystem regularily and will tell Netapp which blocks can be freed. In this case your used space will also decrease on Netapp when you free up space in your lun.
Grtz, Tom
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Daniel Keisling Sent: vrijdag 25 januari 2008 23:15 To: toasters@mathworks.com Subject: RE: Thin provisioning LUNs, A-SIS, and notifications
After a couple of replies, I have determined that the volume never decreasing is indeed normal behavior. I started SIS on the volume and the LUN did decrease, with great results.
Now if I can just configure SNMP notification for volume autosize events....
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Daniel Keisling Sent: Friday, January 25, 2008 12:07 PM To: toasters@mathworks.com Subject: Thin provisioning LUNs, A-SIS, and notifications
Hello,
I am starting to thin provision LUNs (lun set reservation disable) in order to start using A-SIS on some large (1TB) volumes. Before I turn A-SIS on, I started testing these LUNs and do see the space on the filer grow accordingly with writes on the host. However, the space never seems to go down when I delete files on the host:
rtpstore2b> df /vol/iscsi Filesystem kbytes used avail capacity Mounted on /vol/iscsi/ 10485760 9974748 511012 95% /vol/iscsi/ /vol/iscsi/.snapshot 0 0 0 ---% /vol/iscsi/.snapshot
[root@vrhel5 /]# df /mnt/iscsi Filesystem 1K-blocks Used Available Use% Mounted on /dev/sde1 10321192 7804844 1992064 80% /mnt/iscsi
I see that when I begin writing again, the filer space won't start increasing until there is an increase in space above what the filter already thinks. Is this behavior normal? When I turn SIS on, will the filer LUN size reduce as blocks are deduplicated so that I can then reduce the volume?
Lastly, I will definitely need to know when my volumes autosize so I can focus my attention on not having the aggregate fill up. It would be wonderful if I could set up an SNMP trap to send to Nagios for notification. Before I dig into the MIBs and create the custom trap (if I even can), has anyone done anything similar they could share?
TIA,
Daniel
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
______________________________________________________________________ This email transmission and any documents, files or previous email messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution or use of this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return email and delete the original transmission and its attachments without reading or saving in any manner.
-
Daniel Keisling -
De Wit Tom (Consultant)