All of lore.kernel.org
 help / color / mirror / Atom feed
From: "koraynilay" <koray.fra@gmail.com>
To: "koraynilay" <koray.fra@gmail.com>, "Qu Wenruo" <wqu@suse.com>,
	"Zygo Blaxell" <ce3g8jdj@umail.furryterror.org>
Cc: "Qu Wenruo" <quwenruo.btrfs@gmx.com>, <clm@fb.com>,
	<dsterba@suse.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 0/4] btrfs: add per-inode compression levels in xattrs
Date: Tue, 11 Aug 2026 00:41:55 +0200	[thread overview]
Message-ID: <DKLMK2MR5D7W.25SJ3IBJJ5QID@gmail.com> (raw)
In-Reply-To: <DKKUZT0LUJOI.RE9GG62MU6K3@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

On Mon Aug 10, 2026 at 3:05 AM CEST, koraynilay wrote:
> On Mon Aug 10, 2026 at 2:51 AM CEST, Qu Wenruo wrote:
>>>>>> So either option 2 or 3 would be fine to me. Although I personally prefer
>>>>>> option 3 a little more, just because it's much cleaner code wise.
>>>>>
>>>>> Option 2 preserves legacy behavior that is 12 years old now, and it
>>>>> costs a single comparison in two 'if' statements.
>>>>>
>>>>> Option 3 makes an already confusing situation worse--it makes the
>>>>> underspecified behavior change depending on kernel version.
>>>>
>>>> One should never rely on something not documented in the first place.
>>> 
>>> Option 3 prevents existing mount-option compression level specifications
>>> from working when the attribute agress with the mount option; otherwise,
>>> they would be blocked by a btrfs.compression string that doesn't specify
>>> a level.  That's a _regression_.
>>
>> Let me be this clear, the current one nor option 2 is not working either.
>>
>> If the current algo is different from the XATTR algo, it will be 
>> whatever random number clamped to the XATTR algo for the current code.
>>
>> This applies to the option 2 solution. When mount option changed, the 
>> level will suddenly change from whatever previous mount option to the 
>> default.
>
> TBF, I can see how it could be useful (or rather, how it could be good
> to have it as an option) to have some files with btrfs.compression="zstd"
> and then use -o compress= to decide on the fly how much compressed the
> new data added to them should be.
> Both are (read: will be, after the per-inode patch) 1 command away, but
> there *might* be use-cases where mount is more suitable.
>
>

Hi,

after a little bit of discussion on #btrfs on IRC, kepstin and I drafted
a doc change[1] on a variant of option 2, a bit more clear and expanding
also on the per-inode level change.

Thanks


Best,
koraynilay

[1]: https://github.com/kdave/btrfs-progs/pull/1152

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      parent reply	other threads:[~2026-08-10 22:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08  2:34 [PATCH 0/4] btrfs: add per-inode compression levels in xattrs koraynilay
2026-08-08  2:34 ` [PATCH 1/4] btrfs: export btrfs_match_compress_type(), move it to compression.h koraynilay
2026-08-08  2:34 ` [PATCH 2/4] btrfs: also validate compression levels in btrfs_compress_is_valid_type() koraynilay
2026-08-08  2:34 ` [PATCH 3/4] btrfs: add per-inode compression levels in xattrs koraynilay
2026-08-08  2:34 ` [PATCH 4/4] btrfs: support inheritance for per-inode compression levels koraynilay
2026-08-09  0:17 ` [PATCH 0/4] btrfs: add per-inode compression levels in xattrs Qu Wenruo
2026-08-09  0:35   ` koraynilay
2026-08-09  1:00     ` Qu Wenruo
2026-08-09  1:32       ` koraynilay
2026-08-09 23:17       ` Zygo Blaxell
2026-08-09 23:20         ` Qu Wenruo
2026-08-10  0:28           ` Zygo Blaxell
2026-08-10  0:51             ` Qu Wenruo
2026-08-10  0:57               ` Zygo Blaxell
2026-08-10  1:05               ` koraynilay
2026-08-10  1:54                 ` Qu Wenruo
2026-08-10  1:57                   ` koraynilay
2026-08-10  1:57                     ` Qu Wenruo
2026-08-10  2:06                       ` Zygo Blaxell
2026-08-10  2:11                         ` Qu Wenruo
2026-08-10 22:41                 ` koraynilay [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=DKLMK2MR5D7W.25SJ3IBJJ5QID@gmail.com \
    --to=koray.fra@gmail.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /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.