On 07/22/2017 05:00 AM, Adam Borowski wrote:
On Fri, Jul 21, 2017 at 11:37:49PM +0500, Roman Mamedov wrote:
On Fri, 21 Jul 2017 13:00:56 +0800
Anand Jain <anand.j...@oracle.com> wrote:
On 07/18/2017 02:30 AM, David Sterba wrote:
This must stay 'return 1', if force-compress is on, so the change is
reverted.
Initially I thought 'return 1' is correct, but looking in depth,
it is not correct as below..
The biggest beneficiary of the estimating the compression ratio
in advance (heuristic) is when customers are using the
-o compress-force. But 'return 1' here is making them not to
use heuristic. So definitely something is wrong.
man mount says for btrfs:
If compress-force is specified, all files will be compressed, whether
or not they compress well.
So compress-force by definition should always compress all files no matter
what, and not use any heuristic. In fact it has no right to, as user forced
compression to always on. Returning 1 up there does seem right to me.
Oh yes. I mean to say as the try and compress happens at
btrfs_compress_pages() and compress_file_range(), so in fact,
heuristic should not come in inode_need_compress() at all.
Thanks, Anand
Technically, for every compression algorithm other than identity (and its
bijections), some data will expand by at least one bit (thus byte, thus
page), therefore we need to be able to store with no compression even when
forced. On the other hand, it sounds reasonable to take force to mean
"compression will always be attempted" -- ie, we forbid early return when
a small sample seems uncompressible.
-o compress is about the whether each of the compression-granular bytes
(BTRFS_MAX_UNCOMPRESSED) of the inode should be tried to compress OR
just give up for the whole inode by looking at the compression ratio
of the current compression-granular.
This approach can be overridden by -o compress-force. So in
-o compress-force there will be a lot more efforts in _trying_
to compression than in -o compress. We must use heuristic for
-o compress-force.
Semantic and the user expectation of compress-force dictates to always
compress without giving up, even if it turns out to be slower and not providing
much benefit.
Another question is, how would "compress-force" differ from "compress"
otherwise? Always attempting the compression is its whole purpose!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
