All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Jones <paul@pauljones.id.au>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	Graham Cobb <g.btrfs@cobb.uk.net>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: RE: Question: how understand the raid profile of a btrfs filesystem
Date: Wed, 25 Mar 2020 04:30:16 +0000	[thread overview]
Message-ID: <SYBPR01MB38972C6A31FA985B0D9494109ECE0@SYBPR01MB3897.ausprd01.prod.outlook.com> (raw)
In-Reply-To: <20200325040950.GV13306@hungrycats.org>

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org <linux-btrfs-
> owner@vger.kernel.org> On Behalf Of Zygo Blaxell
> Sent: Wednesday, 25 March 2020 3:10 PM
> To: Graham Cobb <g.btrfs@cobb.uk.net>
> Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
> Subject: Re: Question: how understand the raid profile of a btrfs filesystem

> Disk removes are where the current system breaks down.  'btrfs device
> remove' is terrible:
> 
> 	- can't cancel a remove except by rebooting or forcing ENOSPC
> 
> 	- can't resume automatically after a reboot (probably a good
> 	thing for now, given there's no cancel)
> 
> 	- can't coexist with a balance, even when paused--device remove
> 	requires the balance to be _cancelled_ first
> 
> 	- doesn't have any equivalent to the 'convert' filter raid
> 	profile target in balance info
> 
> so if you need to remove a device while you're changing profiles, you have to
> abort the profile change and then relocate a whole lot of data without being
> able to specify the correct target profile.
> 
> The proper fix would be to reimplement 'btrfs dev remove' using pieces of
> the balance infrastructure (it kind of is now, except where it's not), and so
> 'device remove' can keep the 'convert=' target.  Then you don't have to lose
> the target profile while doing removes (and fix the other problems too).

I've often thought it would be handy to be able to forcefully set the disk size or free space to zero, like how it is reported by 'btrfs fi sh' during a remove operation. That way a balance operation can be used for various things like profile changes or multiple disk removals (like replacing 4x1T drives with 1x4T drive) without unintentionally writing a bunch of data to a disk you don't want to write to anymore.
It would also allow for a more gradual removal for disks that need replacing but not as an emergency, as data will gradually migrate itself to other discs as it is COWed.

Paul.

  reply	other threads:[~2020-03-25  4:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20 17:56 Question: how understand the raid profile of a btrfs filesystem Goffredo Baroncelli
2020-03-21  3:29 ` Zygo Blaxell
2020-03-21  5:40   ` Andrei Borzenkov
2020-03-21  7:14     ` Zygo Blaxell
2020-03-21  9:55   ` Goffredo Baroncelli
2020-03-21 23:26     ` Zygo Blaxell
2020-03-22  8:34       ` Goffredo Baroncelli
2020-03-22  8:38         ` Goffredo Baroncelli
2020-03-22 23:49           ` Zygo Blaxell
2020-03-23 20:50             ` Goffredo Baroncelli
2020-03-23 22:48               ` Graham Cobb
2020-03-25  4:09                 ` Zygo Blaxell
2020-03-25  4:30                   ` Paul Jones [this message]
2020-03-26  2:51                     ` Zygo Blaxell
2020-03-23 23:18               ` Zygo Blaxell
2020-03-24  4:55 ` Anand Jain
2020-03-24 17:59   ` Goffredo Baroncelli
2020-03-25  4:09     ` Andrei Borzenkov
2020-03-25 17:14       ` Goffredo Baroncelli
2020-03-26  3:10         ` Zygo Blaxell
2020-03-20 17:58 Goffredo Baroncelli

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=SYBPR01MB38972C6A31FA985B0D9494109ECE0@SYBPR01MB3897.ausprd01.prod.outlook.com \
    --to=paul@pauljones.id.au \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=g.btrfs@cobb.uk.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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.