This is the amount of data changed on a LUN since snapshot has been taken. It looks like LUN was almost completely rewritten since snapshot had been taken. As example, restoring full backup would have this effect.
not sure if I can delete the snapshots.
Well ... it is up to you of course. But you are rsking running out of space on this volume which will result in LUN going offline. You should either plan to increase volume size or celan up unused snapshots and reconsider snapshot policy.
The LUN reservation is important, not the volume reservation. In the lun show you have:
Space Reservation: disabled
This means that the LUN appears as 400gb to the host, but in the volume it actually occupies only the data written from the host. When you created the LUN it occupied zero space, and as the host started writting data in it, it started occupying space in the volume. But the volume already had snapshots, and there was not 400gb free. Eventually as the host writed data, the LUN grew so much that the volume became full.
In the volume you already have 332gb of snapshots. If the LUN gets full, the total space you would have is 332+400=732gb. That's above your volume size and explains why it get filled up.
You can try to enable the lun reservation, but the system will not let you do it because now you do not have enough space in the volume because of the snapshots.
At this point you must start fresh and bring the volume to a balance.
1. if you can, delete your snapshots. "Can" means that they are not needed for some reason. If for example you have snapmirror or snapvault, the you cannot delete them, because some of them are needed for the mirror or snapvault. Do a snap list and identify your snapshots. If you have deleted all your snapshots, then the volume will have only the LUN in it. Bring the LUN online and use it normally from the host. If you want to have snapshots of your data you should start with a big volume (i.e. 2x400 = 800gb) asuming that all the data in the LUN have changed and you need to keep the old image in one snapshot. Leave it running for some days/weeks and see what the actual stats are with df. Remember as snapshots grow older they grow larger too (more changes accumulated), so you might consider keeping snapshots for a small time (and then moving to backup for example). This needs a snapshot and backup policy to be defined.
2. If you cannot delete all the snapshots and start fresh, then you have no option but to enlarge your volume say to 750 or 800gb. Then leave the host running for some time and the same time recycle your snapshots depending on why they are used. If they are used for snapmirror/snapvault do some mirror updates to clearup the old snapshots and create newer (and smaller) ones. If they are used for backup reasons, create new ones and delete the older ones. New snapshots are always small in size. I guess your existing snapshots will be old by now and this explains their size. Build a snapshot policy with not too old snapshots and leave it running for some time to clear the old large snapshots. After you have come to a balance, you will see how much space snapshots actually occupy with df, and reduce the volume size to something normal, e.g. +30% above used space.
At this point you probably have old snapshots, you have brought the LUN online/offline several times, data copied in by the host several times and this makes your snapshots grow above normal. It is important to start fresh somehow and bring your volume to a balanced size.
Let us know how it went and what your concerns are. I am not sure what you mean with "not sure if I can delete the snapshots.". Why is this? Who creates the snapshots?
If space is a concern to you, you do need a snapshot policy, however simple or complex it may be. But first you have to get the system running.
since you have lun reservation disabled 351gb is about the actual data in the LUN, as seen from the host.
if you enable the lun reservation you will always see 400gb used in the volume, no matter if the LUN is full or empty from the host.
it is nice that the snapshots have decreased. This happenned because a newer snapshots was created and the older one deleted.
leave it running like that for some time and check the sizes. You still have the risk of snapshots getting too big, if for example if the host deleted all the 351gb and wrote fresh data in. The snapshots would then get all the old 351gb (to be able to restore to the previous state) and eventually your volume would get full. Unfortunately, you cannot avoid this risk. Enabling lun reservation will not help with such situations of snapshot size increase.
if you want to be ~100% sure that there will be no problems with full volume and the lun getting offline, you have to:
enable lun reservation
define a policy for automatic volume growth and/or automatic snapshot deletion for this volume
If snapshots are important, i.e. applications rely on them, and not just for backup reasons, automatic snapshot deletion is acceptable provided that you have other backups of your data.
Automatic volume growth is also acceptable, given that you have space in your aggregate.
Both methods are helpful, and can save you from vol offline situations,
Snapshots are a greate way to have instant online backups with small space requirements, and very fast restores, but their size is statistical, depending on the changes made from hosts. This is the caveat.
Thin provisioning (lun reservation setting) is also a great way to save space especially in complex environments, because you can sum up and save all the free data not used by hosts. But again the caveat is that this is also statistical.
In all cases, these are statistical data and you cannot be 100% sure, so you have to monitor the system, create auto growth policies, and remediate afterwards, checking what happenned with the snapshots, vol size etc.