All of lore.kernel.org
 help / color / mirror / Atom feed
From: Forza <forza@tnonline.net>
To: Leszek Dubiel <leszek@dubiel.pl>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs not using all devices in raid1
Date: Fri, 21 May 2021 23:53:42 +0200 (GMT+02:00)	[thread overview]
Message-ID: <67da918.7deb9c64.17990eb7cf1@tnonline.net> (raw)
In-Reply-To: <efa44798-ff3e-0dc6-06fb-b5cbf6569d40@dubiel.pl>



---- From: Leszek Dubiel <leszek@dubiel.pl> -- Sent: 2021-05-21 - 23:10 ----

> 
> 
>> Raid1 means two copies on different devices. This is fulfilled with the previous 3 drives so the  'soft' keyword is not going to help here. 
> 
> That's right.
> 
> 
> 
>> You can do a full data balance (-dusage=100) to move some data across to the new disk. There is no need to do a metadata balance in this case, unless you want to convert to raid1c3 to have three copies of metadata. 
> 
> 
> This is production server, and I don't want to do full balance, because it will hit performance for users.
> I hoped that when data gets written to filesysystem BTRFS will choose drive that has most free space, that is /dev/sdc2.
> 
> Is there any way to tell BTRFS to use /dev/sdc2?
> 
> 
> 
> 
>>  If you do nothing, the filesystem will eventually balance itself as you add abs delete data. 
> 
> 
> If I do nothing then /dev/sd{a,b,d}2 would get almost full, and only 
> after /dev/sdc2 would be used?
> 
> 

Btrfs will fill the disk with most unallocated space first.  So eventually they will end up almost equal. 

> 
> 
> Not using /dev/sdc2 is bad because:
> 
> -- maybe this drive is already failed, but nothing is written to it so I 
> have no reports of errors
> 
> -- other drives get all the data, so if one of them fails, then I will 
> have to take longer time to replace it
> 
> I would prefer to have all drives EQUAL in Raid1.
> 
> 
> 

You can run balance with filters to do a little at a time and only use blocks on the other disks. Look at devid and limit https://btrfs.wiki.kernel.org/index.php/Balance_filters





  reply	other threads:[~2021-05-21 22:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 16:34 Btrfs not using all devices in raid1 Leszek Dubiel
2021-05-21 20:11 ` Forza
2021-05-21 21:10   ` Leszek Dubiel
2021-05-21 21:53     ` Forza [this message]
2021-05-22  2:08 ` Zygo Blaxell
2021-05-22  8:52   ` Leszek Dubiel

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=67da918.7deb9c64.17990eb7cf1@tnonline.net \
    --to=forza@tnonline.net \
    --cc=leszek@dubiel.pl \
    --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.