Sounds to me like expected behaviour: if there's zero bytes free on the physical disk, Starwind should refuse to mount a dedupe disk held on it, as deduped disks can only grow, not shrink. Perhaps there should be an option to mount it read only?
It will be interesting to see what happens in V6 with HA dedupe when the physical disk on one (or both) nodes is full / nearly full.
Does the dedupe engine keep track of how many duplicates there are of each unique block? If it did, then this would help in disk full situations, as then blocks that have a quantity of zero could then be removed from the physcial disk, freeing up space for new data, and without having to get into parsing the filesystem held on the target.
Example: imagine that we have a target that has been provisioned as having a capacity of 40KB using 4KB blocks. And for this example, imagine that there are 26 possible blocks represented by A-Z. The physical disk has 80KB space - enough for 20 unique blocks.
Code: Select all
1) Our initiator fills the target with 10 Z blocks:
Target ZZZZZZZZZZ
Disk Z-------------------
Map Z:10
Starwind just writes one Z to the disk, and records that there are 10 duplicates of Z. We have 19 blocks free on our physical disk.
2) The initiator starts writing some random data to the target
Target ZZZZZZZZZZ
Target ITISAPERIO
Disk -ITSAPERO-----------
Map Z:1 I:3 T:2 S:1 A:1 M:1
The new blocks I, T, S, A, P, R and D get written to the disk. Note that the count for Z has disappeared. This was achieved by decrementing the counter for Z each time a Z block was replaced by something else. When it reached zero, the Z block was deleted. We have 11 blocks free on our physical disk.
3) The initiator continues writing some random data to the target
Target DOFCIVILWA
Disk -I--A---ODFCVLW-----
Map I:2 D:1 F:1 C:1 V:1 L:1 W:1 A:1
11 blocks are free
4) The initiator continues channeling GL
Target RREBELSPAC
Disk ----A------C-LWREBSP
Map R:2 E:2 B:1 L:1 S:1 P:1 A:1 C:1
Still 11 blocks are free
If we didn't have this counting method coupled with deleting unused blocks, the physical disk would be looking like this:
1) Z-------------------
2) ZITSAPERO-----------
3) ZITSAPERODFCVLWA----
4) ZITSAPERODFCVLWABP--
only two free blocks; the next two unique blocks written would fill our physical disk.
It would seem to me that this method would work regardless of the filesystem, however the overhead in keeping a count for each unique block (starwind already has to store the hash and location) might be quite high. But at least this way there is no way for a dedupe target to run out of physical disk space unless it has been thinly provisioned.
As an additional trick: the blocks with the highest counts could be cached in RAM, and a middle tier could be cached on SSD.
Of course, I have no idea if Starwind is already doing this or something similar!
) : can you just destroy the targets and after to re-create the device. After these actions it is possible that you will have possibility to Storage Motion.