linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Josef Bacik <josef@toxicpanda.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v6 1/5] btrfs: Introduce per-profile available space facility
Date: Fri, 17 Jan 2020 09:54:45 +0800	[thread overview]
Message-ID: <525d34e8-1c14-b13f-bb03-91754e5882f1@gmx.com> (raw)
In-Reply-To: <4380a833-eb7c-cabe-3a97-9346d803873f@toxicpanda.com>


[-- Attachment #1.1: Type: text/plain, Size: 1456 bytes --]



On 2020/1/17 上午9:50, Josef Bacik wrote:
> On 1/16/20 7:55 PM, Qu Wenruo wrote:
>>
>>
>> On 2020/1/17 上午12:14, Josef Bacik wrote:
>>> On 1/16/20 1:04 AM, Qu Wenruo wrote:
>> [...]
>>>
>>> Instead of creating a weird error handling case why not just set the
>>> per_profile_avail to 0 on error?  This will simply disable overcommit
>>> and we'll flush more.  This way we avoid making a weird situation
>>> weirder, and we don't have to worry about returning an error from
>>> calc_one_profile_avail().  Simply say "hey we got enomem, metadata
>>> overcommit is going off" with a btrfs_err_ratelimited() and carry on.
>>> Maybe the next one will succeed and we'll get overcommit turned back
>>> on.  Thanks,
>>
>> Then the next user statfs() get screwed up until next successful update.
>>
> 
> Then do a
> 
> #define BTRFS_VIRTUAL_IS_FUCKED (u64)-1
> 
> and set it to that so statfs can call in itself and re-calculate.  Thanks,

Then either we keep the old behavior (inaccurate for
RAID5/6/RAID1C2/C3), or hold chunk_mutex to do the calculation (slow).
Neither looks good enough to me.

The proper error handling still looks better to me.

Either way, we need to revert the device size when we failed in those 4
timings. With or without the patchset.

Doing proper revert not only enhance the existing error handling, but
also makes the per-profile available array sane.

Thanks,
Qu

> 
> Josef


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-01-17  1:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  6:03 [PATCH v6 0/4] Introduce per-profile available space array to avoid over-confident can_overcommit() Qu Wenruo
2020-01-16  6:04 ` [PATCH v6 1/5] btrfs: Introduce per-profile available space facility Qu Wenruo
2020-01-16 16:14   ` Josef Bacik
2020-01-17  0:55     ` Qu Wenruo
2020-01-17  1:50       ` Josef Bacik
2020-01-17  1:54         ` Qu Wenruo [this message]
2020-01-17  2:00           ` Josef Bacik
2020-01-16  6:04 ` [PATCH v6 2/5] btrfs: space-info: Use per-profile available space in can_overcommit() Qu Wenruo
2020-01-16  6:04 ` [PATCH v6 3/5] btrfs: statfs: Use pre-calculated per-profile available space Qu Wenruo
2020-01-16 16:21   ` Josef Bacik
2020-01-16  6:04 ` [PATCH v6 4/5] btrfs: Reset device size when btrfs_update_device() failed in btrfs_grow_device() Qu Wenruo
2020-01-16  6:04 ` [PATCH v6 5/5] btrfs: volumes: Revert device used bytes when calc_per_profile_avail() failed Qu Wenruo
2020-01-29  5:19 ` [PATCH v6 0/4] Introduce per-profile available space array to avoid over-confident can_overcommit() Qu WenRuo
2020-01-29  9:23   ` Nikolay Borisov
2020-01-29 10:51     ` Qu Wenruo

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=525d34e8-1c14-b13f-bb03-91754e5882f1@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).