Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.org>
To: Filipe Manana <fdmanana@kernel.org>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2] btrfs: defrag: allow fine-tuning on lone extent defrag behavior
Date: Wed, 07 Feb 2024 18:40:52 +0100	[thread overview]
Message-ID: <0bf0c7e2e6fc023d6c1ea14b09fe509ce1c32ba5.camel@scientia.org> (raw)
In-Reply-To: <CAL3q7H7nbjJhZiE+VMxBui5zgEGBNjO+J=SF9WrmtRETpT8P_g@mail.gmail.com>

On Wed, 2024-02-07 at 12:27 +0000, Filipe Manana wrote:
> A percentage, in the integer range from 1 to 99% for example, is a
> lot
> more user friendly, intuitive, obvious.

If by that you'd mean the percentage of wasted storage, then I'm not
really sure whether I can agree to that.

Especially percentage of what? The original untruncated extent size?
The user would never really know what that is.


If I have e.g. a 10.000 files with extent sizes of 1 GB, then 10%
wasted may already be too much for me.

But if I had 10.000 files with extents sizes of 1MB, the same 10% may
not be that much of a problem.

OTOH, if I have  10 million files with extent sizes of a few kB, than
even 1% might be already too much.



If the clean up of such wasted space is a manual operation, then I
would be best if one could somehow see not only how much is wasted
(which can, to some extent already be done via compsize) but also some
estimates how that is distributed like in the examples above... and
from that, which precentage or ratio or whatever one has to specify for
clean up to get so and so much wasted storage back.



Cheers
Chris.

  reply	other threads:[~2024-02-07 18:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-05 23:45 [PATCH 0/2] btrfs: defrag: better lone extent handling Qu Wenruo
2024-02-05 23:45 ` [PATCH 1/2] btrfs: defrag: add under utilized extent to defrag target list Qu Wenruo
2024-02-06 16:23   ` Filipe Manana
2024-02-06 20:41     ` Qu Wenruo
2024-02-06 22:26       ` Qu Wenruo
2024-02-07 12:19       ` Filipe Manana
2024-02-05 23:45 ` [PATCH 2/2] btrfs: defrag: allow fine-tuning on lone extent defrag behavior Qu Wenruo
2024-02-06 17:03   ` Filipe Manana
2024-02-06 20:50     ` Qu Wenruo
2024-02-07 12:27       ` Filipe Manana
2024-02-07 17:40         ` Christoph Anton Mitterer [this message]
2024-02-06 20:27 ` [PATCH 0/2] btrfs: defrag: better lone extent handling Christoph Anton Mitterer

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=0bf0c7e2e6fc023d6c1ea14b09fe509ce1c32ba5.camel@scientia.org \
    --to=calestyo@scientia.org \
    --cc=fdmanana@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox