Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: VDO slow TRIM/Discard workaround #74

Open
jtblck90 opened this issue Dec 13, 2023 · 2 comments
Open

Question: VDO slow TRIM/Discard workaround #74

jtblck90 opened this issue Dec 13, 2023 · 2 comments

Comments

@jtblck90
Copy link

I'm using large VDO volumes and as per recommendation, to avoid performance degradation during TRIM/Discard operations, I disable TRIM/Discard. However, after some time (after deleting files, for example), VDO will show incorrect info on free/used space and as a result, incorrect deduplication savings. My workaround to this is to create a file with the size of free space left on the volume and fill it with zeroes and then delete it. But wanted to ask, perhaps, there are other, better workarounds?

Also, do you know if there are any plans to fix/improve slow TRIM/Discard in VDO?

@tigerblue77
Copy link

Hello, I think that the performance degradation of a manual trim is the same than your workaround. I did use VDO :

  • with discard
  • without discard but by running fstrim regularly (say, once a month)
    Of course, as both generates I/O, you get a performance penalty but it's you to adapt to your workload. Do you prefer the permanent low penalty of discard or sometimes a high penalty coming from writing a big zeroed file or trimming ? (correct me if I'm wrong)

@raeburn
Copy link
Member

raeburn commented Jan 3, 2024

Yes, as tigerblue77 points out, the cost for writing zero blocks will be about the same as for discarding blocks. There are circumstances where writing a zero block can be more expensive, but once you've filled out the address mapping trees by filling the file system, they're basically the same.

VDO's information on space savings is correct as far as VDO is concerned -- if no discard has been sent down, then the block is still considered in use, even if the file system chooses not to use it any more. VDO isn't allowed to reuse the backing storage for anything else until all references are discarded or overwritten. If the file system chooses to allocate new blocks instead of overwriting the previous ones, those previous ones aren't available for VDO to reuse.

We've got some ideas in the works that may mitigate the cost of discards, but most of the team's effort has been focused on getting upstream submissions prepared.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants