Hi!
First I want to confirm, that the registry entry RefsEnableInlineTrim=1 is working an prevents the server from freezing.
Nevertheless deleting huge files takes a lot of time. On my small veeam server approximately 1.1-1.2 TB are set free per hour. That means after deleting the space occupied by the deleted file is marked as "system reserved" in the advanced properties of the drive. During all this time the system is permanetly writing on the drive at maximum speed. The total amount written is aproximately 33% of the file size of the deleted file.
I think this is caused by the CoW policy:
"Copy-On-Write (COW) is an update policy that may be used to alter data on a storage medium. A COW
update policy makes sure that data is never updated data in place. Whenever the contents of a block should
be altered, the block is read into memory, modified and its contents are written to an alternate location on the
storage medium." (from Technical Reports / ISSN 2191-5008 https://d-nb.info/1201551625/34)
Since the meta data of the file consists of B+-trees, which has a lot of leaves if it's a big file, the system writes the whole new tree to disk for every cutted leaf. So this data is scaling with (number of leaves) times (number of leaves).
I also tried to reduce the number of leaves by using explorer's copy function to copy a huge fie. The required space on the destination disk is immediately occupied. But the effect on the duration of the deleion and free up space process is very limited (10%).
So any backup process requiring deletion of huge files is affected an will need much more time e.g. several hours depending on filesize.
MS has to solve this! Can anybody put some pressure on them?
Jo
First I want to confirm, that the registry entry RefsEnableInlineTrim=1 is working an prevents the server from freezing.
Nevertheless deleting huge files takes a lot of time. On my small veeam server approximately 1.1-1.2 TB are set free per hour. That means after deleting the space occupied by the deleted file is marked as "system reserved" in the advanced properties of the drive. During all this time the system is permanetly writing on the drive at maximum speed. The total amount written is aproximately 33% of the file size of the deleted file.
I think this is caused by the CoW policy:
"Copy-On-Write (COW) is an update policy that may be used to alter data on a storage medium. A COW
update policy makes sure that data is never updated data in place. Whenever the contents of a block should
be altered, the block is read into memory, modified and its contents are written to an alternate location on the
storage medium." (from Technical Reports / ISSN 2191-5008 https://d-nb.info/1201551625/34)
Since the meta data of the file consists of B+-trees, which has a lot of leaves if it's a big file, the system writes the whole new tree to disk for every cutted leaf. So this data is scaling with (number of leaves) times (number of leaves).
I also tried to reduce the number of leaves by using explorer's copy function to copy a huge fie. The required space on the destination disk is immediately occupied. But the effect on the duration of the deleion and free up space process is very limited (10%).
So any backup process requiring deletion of huge files is affected an will need much more time e.g. several hours depending on filesize.
MS has to solve this! Can anybody put some pressure on them?
Jo
Statistics: Posted by jokoenen — Oct 14, 2025 8:43 am
