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

Alternative fuse mount method on OpenVZ #1466

Closed
pepa65 opened this issue Aug 12, 2016 · 3 comments
Closed

Alternative fuse mount method on OpenVZ #1466

pepa65 opened this issue Aug 12, 2016 · 3 comments

Comments

@pepa65
Copy link

pepa65 commented Aug 12, 2016

I have an OpenVZ VPS running as a borg repo over ssh. I was trying to borg mount the repo locally on the server, but it got "Killed". As it appears, there is a special setting to allow fuse on OpenVZ. The hoster changed it, and now I can mount things on fuse, but I still can't do "borg mount"... I was wondering whether a way could be found to still mount in this situation.

@pepa65
Copy link
Author

pepa65 commented Aug 12, 2016

I just created a new small repo, and was able to borg mount that. So it's probably more an issue of a resource usage spike (memory) that causes the Kill... This VPS has 128M and 64M swap.

I guess there is no way to limit the memory usage for a borg mount..?!
Is there any way to predict how much memory is needed in case I want to upgrade to more memory??

@ThomasWaldmann
Copy link
Member

Due to the way how borg works, it needs quite some memory, so it might be not suitable for machines with little memory like yours.

How much it needs depends on many factors, like repo size, chunk count, files count, ... (see docs, there are some formulas and explanations).

borg mount loads the complete metadata for all files/dirs in an archive (or, if you mount the repo: in all accessed archives) into memory. so, if you are low on memory, rather use borg list and borg extract.

@ThomasWaldmann
Copy link
Member

Note: it is always "space vs. time". If you make the software use less space (memory), it will often need more time (and vice versa). There likely isn't much we can do to make borg use less memory without making it slower (which is obviously not desired).

#1429 might make borg use a bit less memory than it is using now, due to a better load factor of the hashtable (maybe 95% vs. 75% now). It also might be faster, due to a better algorithm. But: it is only a slight improvement, if you haven't much memory you will still run out of memory at some time.

So, while we can try to improve borg gradually, we maybe can't make it use much less memory.

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

No branches or pull requests

3 participants