anarcat

extracted from https://mail.python.org/pipermail/borgbackup/2016q1/000116.html

the idea of LUKS is that the whole filesystem cannot be easily re-encrypted. it's a separate operation. but the "keyfile" that is used to encrypt the filesystem is a large...

@namepunk can you provide the filename that triggers the crash? you should be able to see where it fails using `-vv`... i wonder if it's a good idea to assume...

from irc://irc.freenodenet/#borg: ``` 15:37:33 maybe the quick fix is to add a --acl flag that'S enabled by default 15:37:39 a bit like what i did with --progress 15:38:09 0xd0 is...

i had the impression this was fixed in #119, did you try with latest git?

take a look at the bup side before jumping into that ship. i heard they discoverd performance problems where such policies would actually _remove_ good contents from the cache that...

the `#bup` people were kind enough to send me a few refs: https://www.percona.com/blog/2010/04/02/fadvise-may-be-not-what-you-expect/ https://groups.google.com/forum/#!topic/bup-list/7D9b2at3MMc https://groups.google.com/forum/#!topic/bup-list/nQ24WCT1g4E it's still subject to discussion on the bup mailing list, but please do be careful...

apparently, the issue came up in this thread: https://groups.google.com/d/msg/bup-list/TXfSAgD9-ZM/saofDu1CdxcJ where bup would trash the sqlite cache of a big file, which had to be reloaded in memory, which was basically...

the last link was where they discovered the issue apparently. for me it makes sense that trashing the cache will have a performance impact. when you load a page in...

hmm... well, the problem described earlier is specifically with stuff like mysql databases that get totally flushed out of the cache, having a major performance impact on the whole system....