From: Roman Mamedov <rm@romanrm.net>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] btrfs: do not allow -o compress-force to override per-inode settings
Date: Mon, 30 Nov 2020 20:01:16 +0500 [thread overview]
Message-ID: <20201130200116.79a710fe@natsu> (raw)
In-Reply-To: <b92d0141-f68f-ce96-8099-e145ebc6f594@toxicpanda.com>
On Mon, 30 Nov 2020 09:50:13 -0500
Josef Bacik <josef@toxicpanda.com> wrote:
> The thing you're missing is that when we do chattr -c we're setting NOCOMPRESS
> on the file.
Wow, and does this need a previously set +c to work? Or just -c on an already
-c file will change the Btrfs flag under the hood? Seems to be very weird in
any case, as from the user perspective there's no way to view the current
status of that flag, with the only way to change it being via a side-effect of
another operation.
> If chattr -c is supposed to just be the removal of +c, then btrfs is doing the
> wrong thing by setting NOCOMPRESS.
I would agree with that.
> I guess the question is what do we want? Do we want to only allow the user to
> indicate we want compression, or do we want to allow them to also indicate that
> they don't want compression? If we don't want to enable them to disable
> compression for a file, then this patch needs to be thrown away, but then we
> also need to fix up all the places we set NOCOMPRESS when we clear these flags.
The patch also seems to prioritize "no compress if compression ratio is bad"
over compress-force, whereas the whole point of compress-force feels to be to
compress no matter what, especially no matter what are the possibly imperfect
compression ratio estimates.
--
With respect,
Roman
next prev parent reply other threads:[~2020-11-30 15:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 13:46 [PATCH] btrfs: do not allow -o compress-force to override per-inode settings Josef Bacik
2020-11-30 14:08 ` Roman Mamedov
2020-11-30 14:27 ` Amy Parker
2020-11-30 14:50 ` Josef Bacik
2020-11-30 15:01 ` Roman Mamedov [this message]
2020-11-30 15:10 ` Josef Bacik
2020-11-30 15:17 ` Roman Mamedov
2020-11-30 15:04 ` Hugo Mills
2020-11-30 15:12 ` Josef Bacik
2020-11-30 17:28 ` sys
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=20201130200116.79a710fe@natsu \
--to=rm@romanrm.net \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox