All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Roman Mamedov <rm@romanrm.net>
Cc: Dave Chinner <david@fromorbit.com>, linux-btrfs@vger.kernel.org
Subject: Re: Unexpected reflink/subvol snapshot behaviour
Date: Sat, 23 Jan 2021 18:58:49 +0800	[thread overview]
Message-ID: <aece4c0c-c0a1-accd-d7b2-99ff1327de72@gmx.com> (raw)
In-Reply-To: <20210123153933.534a43ea@natsu>



On 2021/1/23 下午6:39, Roman Mamedov wrote:
> On Sat, 23 Jan 2021 16:42:33 +0800
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>> For the worst case, btrfs can allocate a 128 MiB file extent, and have
>> good luck to write 127MiB into the extent. It will take 127MiB + 128MiB
>> space, until the last 1MiB of the original extent get freed, the full
>> 128MiB can be freed.
>
> Does it mean enabling compression actually mitigates this issue as a
> side-effect? Since each extent will be limited to only 128K.

Yes! Compression brings the side effect of reducing the maximum data
extent size, thus mitigates the problem by 1024.

But the problem is still there.

Thanks,
Qu
>
> What are the typical extent sizes without compression?
>

  reply	other threads:[~2021-01-23 11:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 22:20 Unexpected reflink/subvol snapshot behaviour Dave Chinner
2021-01-23  8:42 ` Qu Wenruo
2021-01-23  8:51   ` Qu Wenruo
2021-01-23 10:39   ` Roman Mamedov
2021-01-23 10:58     ` Qu Wenruo [this message]
2021-01-24 13:08   ` Filipe Manana
2021-01-24 22:36   ` Dave Chinner
2021-01-25  1:09     ` Qu Wenruo
2021-01-29 23:25     ` Zygo Blaxell
2021-02-02  0:13       ` Dave Chinner
2021-02-12  3:04         ` Zygo Blaxell
2021-01-24  0:19 ` Zygo Blaxell
2021-01-24 21:43   ` Dave Chinner
2021-01-30  1:03     ` Zygo Blaxell
2021-02-02  2:14 ` Darrick J. Wong
2021-02-02  6:02   ` Dave Chinner

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=aece4c0c-c0a1-accd-d7b2-99ff1327de72@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=david@fromorbit.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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.