From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, Adam Borowski <kilobyte@angband.pl>,
Roman Mamedov <rm@romanrm.net>,
Timofey Titovets <nefelim4ag@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3] Btrfs: add skeleton code for compression heuristic
Date: Fri, 28 Jul 2017 23:04:11 +0900 [thread overview]
Message-ID: <597B445B.9070107@oracle.com> (raw)
In-Reply-To: <20170727153653.GO2866@twin.jikos.cz>
On 28/07/2017 00:36, David Sterba wrote:
> On Mon, Jul 24, 2017 at 11:40:17PM +0800, Anand Jain wrote:
>>
>>> Eg. files that are already compressed would increase the cpu consumption
>>> with compress-force, while they'd be hopefully detected as
>>> incompressible with 'compress' and clever heuristics. So the NOCOMPRESS
>>> bit would better reflect the status of the file.
I thought 'compress' in above, is the compress option. Ah you mean
to say compression algo .. got it. Right compress-force for
incompressible-data is very expensive.
And its also true that compress option for incompressible data is
not at all expensive and its only one time.
>> current NOCOMPRESS is based on trial and error method and is more
>> accurate than heuristic also loss of cpu power is only one time ?
> Curreently, force-compress beats everything, so even a file with
> NOCOMPRESS will be compressed, all new writes will be passed to the
> compression and stored uncompressed eventually.
It makes sense to me when you replace NOCOMPRESS with
incompressible-data in the above statement. As in my understanding..
You will never have a file with NOCOMPRESS flag if compress-force
option is used.
> Each time they
> compression code will run and fail, so it's not one time.
>
> Although you can say it's more 'accurate', it's also more expensive.
yes. Expensive only in compress-force.
>> May be the only opportunity that heuristic can facilitate is at the
>> logic to monitor and reset the NOCOMPRESS, as of now there is no
>> such a logic.
>
> The heurictic can be made adaptive, and examine data even for NOCOMPRESS
> files, but that's a few steps ahead of where we are now.
Nice.
Thanks, Anand
prev parent reply other threads:[~2017-07-28 14:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-17 13:52 [PATCH v3] Btrfs: add skeleton code for compression heuristic Timofey Titovets
2017-07-17 18:30 ` David Sterba
2017-07-21 5:00 ` Anand Jain
2017-07-21 18:37 ` Roman Mamedov
2017-07-21 21:00 ` Adam Borowski
2017-07-22 0:52 ` Anand Jain
2017-07-24 14:53 ` David Sterba
2017-07-24 15:40 ` Anand Jain
2017-07-27 15:36 ` David Sterba
2017-07-28 14:04 ` Anand Jain [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=597B445B.9070107@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=kilobyte@angband.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=nefelim4ag@gmail.com \
--cc=rm@romanrm.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.