-
Notifications
You must be signed in to change notification settings - Fork 16
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
Rustic restore slower than Restic when there are huge numbers of files. #32
Comments
Thanks a lot for opening this issue! Anyway, I am irritated by the fact that using names instead of uid/gid takes so much longer... I expected those to be cached so that each name has to be resolved just once. I'll have a look at it soon... BTW: moved this to rustic_core as this is an issue within this crate. |
Ok, I realized that there is no caching - I think this was lost when we changed it using the nix crate - IIRC this was due to some security alerts in the crate we used before... So this explains it - each name is resolved by a syscall which is not optimal - we should add a caching again here. |
Also keep in mind that there may be nothing to cache, because... the user may not exist. |
About the default: AFAIK GNU tar also restores by default using user/group names instead of the uid/gid and this was influencing the choice of rustic's default behavior. In #33 caching for uids/gids has been added. If you have many users/groups, this will take some memory, yes. But I think the performance gain should be worth it. |
And restore is slower even if the files are already existing.
strace
The situation is greatly improved by --numeric-id (~16m to restore), but I don’t understand why it chowns and chmods if nothing has changed, It spends half the time on this (I ran several times sequentially):
Perhaps it's worth making numeric-id the default?
The text was updated successfully, but these errors were encountered: