Some additional info - the reported Volume Space In-Use matches the initial sync amount of 71.06GB. Even though the volume in Windows is only using 20GB.
Is there a way to shrink the reported In-Use size back down to 20GB? The volume, a few weeks ago, did hold more data that has since been moved elsewhere.
To add to Don's information, I usually explain the mismatch in volume reserve versus used disk space as follows:
In Windows (really most/all OSes), when you delete a file, the file doesn't really get deleted; instead the disk space is marked as being available to store something new. A SAN being a block level storage device cannot tell the difference, so it cannot see that the disk space has been freed up, and therefor still considers the 71GB in use.
The SCSI unmap command allows the server to 'tell' the SAN that that disk space is now no longer needed and it lets the volume reserve lower. This can help with thin provisioned volumes.
If my understanding is correct, I think that if you use the SCSI unmap (if you have the right OS and hitkit installed) before you set up replication and reduce the volume reserve. After this you can configure the volume for replication and only have to replicate 20GB. However, if you ever re-fill it (to 70GB or whatever size) you cannot repeat the unmap (maybe unless you completely remove the replication, re-thin and then re-establish replication (and it'll have to do a full replication again for the first run).
Davan
28 Posts
0
March 4th, 2013 10:00
Some additional info - the reported Volume Space In-Use matches the initial sync amount of 71.06GB. Even though the volume in Windows is only using 20GB.
Is there a way to shrink the reported In-Use size back down to 20GB? The volume, a few weeks ago, did hold more data that has since been moved elsewhere.
Dev Mgr
4 Operator
•
9.3K Posts
0
March 5th, 2013 10:00
To add to Don's information, I usually explain the mismatch in volume reserve versus used disk space as follows:
In Windows (really most/all OSes), when you delete a file, the file doesn't really get deleted; instead the disk space is marked as being available to store something new. A SAN being a block level storage device cannot tell the difference, so it cannot see that the disk space has been freed up, and therefor still considers the 71GB in use.
The SCSI unmap command allows the server to 'tell' the SAN that that disk space is now no longer needed and it lets the volume reserve lower. This can help with thin provisioned volumes.
If my understanding is correct, I think that if you use the SCSI unmap (if you have the right OS and hitkit installed) before you set up replication and reduce the volume reserve. After this you can configure the volume for replication and only have to replicate 20GB. However, if you ever re-fill it (to 70GB or whatever size) you cannot repeat the unmap (maybe unless you completely remove the replication, re-thin and then re-establish replication (and it'll have to do a full replication again for the first run).
Don may correct me on this though.