On 2015-12-02 09:03, Imran Geriskovan wrote:
I'm not certain how BTRFS does it, but my guess would be trying to compress the block, then storing the uncompressed version if the compressed one is bigger.What are your disk space savings when using btrfs with compression?* There's the compress vs. compress-force option and discussion. A number of posters have reported that for mostly text, compress didn't give them expected compression results and they needed to use compress- force."compress-force" option compresses regardless of the "compressibility" of the file. "compress" option makes some inference about the "compressibility" and decides to compress or not. I wonder how that inference is done? Can anyone provide some pseudo code for it?
The program lrzip has an option to do per-block compression checks kind of like this, but it's method is to try LZO compression on the block (which is fast), and only use the selected compression method (bzip2 by default I think, but it can also do zlib and xz) if the LZO compression ratio is is good enough. If we went with a similar method, I'd say we should integrate LZ4 support first, and use that for the test. I think NTFS compression on Windows might do something similar, but they use an old LZ77 derivative for their compression (I think it's referred to as LZNT1, and it's designed for speed, and usually doesn't get much better than a 30% compression ratio).
On a side note, I really wish BTRFS would just add LZ4 support. It's a lot more deterministic WRT decompression time than LZO, gets a similar compression ratio, and runs faster on most processors for both compression and decompression.
smime.p7s
Description: S/MIME Cryptographic Signature
