You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Zone reset is simply rewriting the write pointer to the beginning without touching the actual zone data. It would be nice and easy to implement a hole punch, file operation freeing the metadata and data of the requested range. That way a backing file can be shrunk to only live zones. It's a bit like thin provisioning, the file starts sparsely allocated (using just the targetcli commands). I've measured the time of the hole punch on a moderately fragmented file on btrfs, with zone size 256M, the fallocate() call takes like 0.1s, ie. 100ms which is IMO acceptable.
There's system command fallocate, with option --dig-holes it can detect zeroed blocks and punch the hole, but for the test image I had the previous non-zero data and as a result only 2G were removed from a 46G backing file.
Zone reset is simply rewriting the write pointer to the beginning without touching the actual zone data. It would be nice and easy to implement a hole punch, file operation freeing the metadata and data of the requested range. That way a backing file can be shrunk to only live zones. It's a bit like thin provisioning, the file starts sparsely allocated (using just the targetcli commands). I've measured the time of the hole punch on a moderately fragmented file on btrfs, with zone size 256M, the fallocate() call takes like 0.1s, ie. 100ms which is IMO acceptable.
Code change goes like
Errors can be ignored, it's just best effort.
The text was updated successfully, but these errors were encountered: