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
Transfer size stats #280
Comments
I see two ways of implementing this:
received-length.sh:
This simply sums up the "len" field from all modified files since the creation of the subvolume. Works fine, as Issues:
I'm planning to implement this either with a new btrbk command, something like This needs some more investigation, maybe there's a nicer way to get the "real size used on disk". |
I would think option 1 would be a reasonable estimate and not need much in the way of overhead. I seem to recall there is another way if qgroups are enabled but in my case that would not help
*edit: remove quoted text*
|
Yes, this is also valuable information. Especially when you want to also have an estimate of the ssh traffic generated by btrbk. Having a command for listing (option 2) has the advantage that it is reproducible, and also works for manually generated backups.
For more accurate results, we need to do more extensive analysis on the block level, which unfortunately is very time consuming. I did some promising tests with |
I was about to file a new issue begging for a new |
It would be nice (perhaps when running
-v run
) to include details about how many bytes were sent which is presumably roughly equivalent of how much space the snapshot will take up based on the previous one? Perhaps this could also be saved somewhere and output in thestats
so you can see roughly what the deltas are between snaps?The text was updated successfully, but these errors were encountered: