All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Chris Murphy <lists@colorremedies.com>,
	Ross Vandegrift <ross@kallisti.us>,
	Josef Bacik <josef@toxicpanda.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: unable to remove device due to enospc
Date: Sun, 16 Jan 2022 08:42:17 +0800	[thread overview]
Message-ID: <ba6db0c3-6605-d5d1-de04-051b9f099547@suse.com> (raw)
In-Reply-To: <CAJCQCtTKd_yMUa_Fr9bGuhPvfYWPuY0=Vs=-+k85gfZJqLK_FA@mail.gmail.com>



On 2022/1/16 08:39, Chris Murphy wrote:
> On Tue, Jan 11, 2022 at 12:41 AM Ross Vandegrift <ross@kallisti.us> wrote:
>>
>> Unallocated:
>>     /dev/mapper/backup      7.24TiB
>>     /dev/mapper/backup_a    2.55TiB
>>     /dev/mapper/backup_b    2.55TiB
> 
> You might be running into this bug I mentioned today in another
> thread. It's an overcommit related bug where the initial overcommit is
> based on a single device's unallocated space, in this case the 7T
> device - but then later logic results in ENOSPC because there aren't
> two devices that can handle that amount of overcommit. If you  can
> remove /dev/mapper/backup, leaving just _a and _b with equal
> unallocated, then try to reproduce. If you can't, you've likely hit
> the bug I'm thinking of. If you still can, then you're hitting
> something different.

I tend to believe it's a bug related to recent flush bugs Josef is 
trying to solve.

Adding Josef to the thread.

Thanks,
Qu
> 
> However, since these unallocated values are orders of magnitude bigger
> than discussed in the other thread, and orders of magnitude more space
> than is needed to successfully create new chunks on multiple devices -
> I'm not sure. Also I'm not sure without going through the change log
> for 5.15 and 5.16 if this is fixed in one of those so the easiest
> thing to do is try and reproduce it with 5.16. If ENOSPC happens, then
> try to remove the device with 7T unallocated.
> 
> 
> 


  reply	other threads:[~2022-01-16  0:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  7:22 unable to remove device due to enospc Ross Vandegrift
2022-01-15 21:38 ` Ross Vandegrift
2022-01-16  0:39 ` Chris Murphy
2022-01-16  0:42   ` Qu Wenruo [this message]
2022-01-16  6:00     ` Chris Murphy
2022-01-16  3:17   ` Ross Vandegrift
2022-01-16  6:48   ` Ross Vandegrift
2022-02-02  6:08     ` Ross Vandegrift
2022-02-02 17:22 ` Zygo Blaxell
2022-02-02 17:58   ` Ross Vandegrift

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=ba6db0c3-6605-d5d1-de04-051b9f099547@suse.com \
    --to=wqu@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=ross@kallisti.us \
    /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.