On Sat, May 26, 2018 at 06:27:57PM -0700, Brad Templeton wrote:
> A few years ago, I encountered an issue (halfway between a bug and a
> problem) with attempting to grow a BTRFS 3 disk Raid 1 which was
> fairly full. The problem was that after replacing (by add/delete) a
> small drive with a larg
Brad Templeton posted on Sun, 27 May 2018 11:22:07 -0700 as excerpted:
> BTW, I decided to follow the original double replace strategy suggested
--
> replace 6TB with 8TB and replace 4TB with 6TB. That should be sure to
> leave the 2 large drives each with 2TB free once expanded, and thus able
>
BTW, I decided to follow the original double replace strategy
suggested -- replace 6TB with 8TB and replace 4TB with 6TB. That
should be sure to leave the 2 large drives each with 2TB free once
expanded, and thus able to fully use all space.
However, the first one has been going for 9 hours and i
Brad Templeton posted on Sat, 26 May 2018 19:21:57 -0700 as excerpted:
> Certainly. My apologies for not including them before.
Aieee! Reply before quote, making the reply out of context, and my
attempt to reply in context... difficult and troublesome.
Please use standard list context-quote, r
Certainly. My apologies for not including them before. As
described, the disks are reasonably balanced -- not as full as the
last time. As such, it might be enough that balance would (slowly)
free up enough chunks to get things going. And if I have to, I will
partially convert to single again.
On 2018年05月27日 10:06, Brad Templeton wrote:
> Thanks. These are all things which take substantial fractions of a
> day to try, unfortunately.
Normally I would suggest just using VM and several small disks (~10G),
along with fallocate (the fastest way to use space) to get a basic view
of the pro
Thanks. These are all things which take substantial fractions of a
day to try, unfortunately.Last time I ended up fixing it in a
fairly kluged way, which was to convert from raid-1 to single long
enough to get enough single blocks that when I converted back to
raid-1 they got distributed to th
On 2018年05月27日 09:49, Brad Templeton wrote:
> That is what did not work last time.
>
> I say I think there can be a "fix" because I hope the goal of BTRFS
> raid is to be superior to traditional RAID. That if one replaces a
> drive, and asks to balance, it figures out what needs to be done to
That is what did not work last time.
I say I think there can be a "fix" because I hope the goal of BTRFS
raid is to be superior to traditional RAID. That if one replaces a
drive, and asks to balance, it figures out what needs to be done to
make that work. I understand that the current balance a
On 2018年05月27日 09:27, Brad Templeton wrote:
> A few years ago, I encountered an issue (halfway between a bug and a
> problem) with attempting to grow a BTRFS 3 disk Raid 1 which was
> fairly full. The problem was that after replacing (by add/delete) a
> small drive with a larger one, there were
A few years ago, I encountered an issue (halfway between a bug and a
problem) with attempting to grow a BTRFS 3 disk Raid 1 which was
fairly full. The problem was that after replacing (by add/delete) a
small drive with a larger one, there were now 2 full drives and one
new half-full one, and bala
For those curious as the the result, the reduction to single and
restoration to RAID1 did indeed balance the array. It was extremely
slow of course on a 12tb array. I did not bother doing this with the
metadata. I also stopped the conversion to single when it had freed up
enough space on t
Henk Slager posted on Fri, 25 Mar 2016 15:35:52 +0100 as excerpted:
> For the original OP situation, with chunks all filled op with extents
> and devices all filled up with chunks, 'integrating' a new 6TB drive
> in an 4TB+3TG+2TB raid1 array could probably be done in a bit unusual
> way in order
On Fri, Mar 25, 2016 at 2:16 PM, Patrik Lundquist
wrote:
> On 23 March 2016 at 20:33, Chris Murphy wrote:
>>
>> On Wed, Mar 23, 2016 at 1:10 PM, Brad Templeton wrote:
>> >
>> > I am surprised to hear it said that having the mixed sizes is an odd
>> > case.
>>
>> Not odd as in wrong, just uncommo
On 23 March 2016 at 20:33, Chris Murphy wrote:
>
> On Wed, Mar 23, 2016 at 1:10 PM, Brad Templeton wrote:
> >
> > I am surprised to hear it said that having the mixed sizes is an odd
> > case.
>
> Not odd as in wrong, just uncommon compared to other arrangements being
> tested.
I think mixed dr
Hi Brad
Just a user here, not a dev.
I think I might have run into a similar bug about 6 months ago.
At the time I was running Debian stable. (iirc that is kernel 3.16
and probably btrfs-progs of a similar vintage).
The filesystem was originally a 2 x 6TB array with a 4TB drive added
later whe
Brad Templeton posted on Wed, 23 Mar 2016 19:49:00 -0700 as excerpted:
> On 03/23/2016 07:33 PM, Qu Wenruo wrote:
>
>>> Still, it seems to me
>>> that the lack of space even after I filled the disks should not
>>> interfere with the balance's ability to move chunks which are found on
>>> both 3 a
Brad Templeton wrote on 2016/03/23 19:49 -0700:
On 03/23/2016 07:33 PM, Qu Wenruo wrote:
The stage I talked about is only for you fill btrfs from scratch, with 3
4 6 devices.
Just as an example to explain how btrfs allocated space on un-even devices.
Then we had 4 + 3 + 6 + 2, but did
On Wed, Mar 23, 2016 at 8:49 PM, Brad Templeton wrote:
> On 03/23/2016 07:33 PM, Qu Wenruo wrote:
>>
>> No, balance is not working like that.
>> Although most user consider balance is moving data, which is partly right.
>> The fact is, balance is, copy-and-delete. And it needs spare space.
>>
>> M
On 03/23/2016 07:33 PM, Qu Wenruo wrote:
>
> The stage I talked about is only for you fill btrfs from scratch, with 3
> 4 6 devices.
>
> Just as an example to explain how btrfs allocated space on un-even devices.
>
>>
>> Then we had 4 + 3 + 6 + 2, but did not add more files or balance.
>>
>>
Brad Templeton wrote on 2016/03/23 19:13 -0700:
On 03/23/2016 06:59 PM, Qu Wenruo wrote:
About chunk allocation problem, I hope to get a clear view of the whole
disk layout now.
What's the final disk layout?
Is that 4T + 3T + 6T + 20G layout?
If so, I'll say, in that case, only fully re-
On 03/23/2016 06:59 PM, Qu Wenruo wrote:
>
> About chunk allocation problem, I hope to get a clear view of the whole
> disk layout now.
>
> What's the final disk layout?
> Is that 4T + 3T + 6T + 20G layout?
>
> If so, I'll say, in that case, only fully re-convert to single may help.
> As ther
Chris Murphy wrote on 2016/03/23 13:33 -0600:
On Wed, Mar 23, 2016 at 1:10 PM, Brad Templeton wrote:
It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4. I will upgrade to
Xenial in April but probably not before, I don't have days to spend on
this. Is there a fairly safe ppa to pull 4.4 or
Chris Murphy posted on Wed, 23 Mar 2016 12:34:10 -0600 as excerpted:
> On Wed, Mar 23, 2016 at 10:51 AM, Brad Templeton
> wrote:
>> Thanks for assist. To reiterate what I said in private:
>>
>> a) I am fairly sure I swapped drives by adding the 6TB drive and then
>> removing the 2TB drive, which
Brad Templeton posted on Wed, 23 Mar 2016 12:10:29 -0700 as excerpted:
> It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4.
Presumably that's a type for btrfs-progs. Either that or Ubuntu's using
a versioning that's totally different than upstream btrfs. For some time
now (since the 3.12 re
On Wed, Mar 23, 2016 at 1:10 PM, Brad Templeton wrote:
> It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4. I will upgrade to
> Xenial in April but probably not before, I don't have days to spend on
> this. Is there a fairly safe ppa to pull 4.4 or 4.5?
I'm not sure.
In olden days, I
> wo
2016-03-23 20:10 GMT+01:00 Brad Templeton :
> It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4. I will upgrade to
> Xenial in April but probably not before, I don't have days to spend on
> this. Is there a fairly safe ppa to pull 4.4 or 4.5?
Use the mainline ppa: http://kernel.ubuntu.com/~ke
It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4. I will upgrade to
Xenial in April but probably not before, I don't have days to spend on
this. Is there a fairly safe ppa to pull 4.4 or 4.5? In olden days, I
would patch and build my kernels from source but I just don't have time
for all the
On Wed, Mar 23, 2016 at 10:51 AM, Brad Templeton wrote:
> Thanks for assist. To reiterate what I said in private:
>
> a) I am fairly sure I swapped drives by adding the 6TB drive and then
> removing the 2TB drive, which would not have made the 6TB think it was
> only 2TB.The btrfs statistics
Thanks for assist. To reiterate what I said in private:
a) I am fairly sure I swapped drives by adding the 6TB drive and then
removing the 2TB drive, which would not have made the 6TB think it was
only 2TB.The btrfs statistics commands have shown from the beginning
the size of the device as 6
On Tue, Mar 22, 2016 at 11:54 PM, Brad Templeton wrote:
> Actually, the URL suggests that all the space will be used, which is
> what I had read about btrfs, that it handled this.
It will. But it does this by dominating writes to the devices that
have the most free space, until all devices have t
On Tue, Mar 22, 2016 at 10:47 PM, Brad Templeton wrote:
> That's rather counter intuitive behaviour. In most FSs, resizes are
> needed when you do things like change the size of an underlying
> partition, or you weren't using all the partition. When you add one
> drive with device add, and you t
That's rather counter intuitive behaviour. In most FSs, resizes are
needed when you do things like change the size of an underlying
partition, or you weren't using all the partition. When you add one
drive with device add, and you then remove another with device delete,
why and how would the adde
Brad Templeton wrote on 2016/03/22 17:47 -0700:
I have a RAID 1, and was running a bit low, so replaced a 2TB drive with
a 6TB. The other drives are a 3TB and a 4TB.After switching the
drive, I did a balance and ... essentially nothing changed. It did not
balance clusters over to the 6TB
34 matches
Mail list logo
