I'll reboot the thread with a recap and my latest findings.
* Half full 3TB disk converted from ext4 to Btrfs, after first
verifying it with fsck.
* Undo subvolume deleted after being happy with the conversion.
* Recursive defrag.
* Full balance, that ended with 98 enospc errors during balance.
On 12/10/2014 05:36 AM, Patrik Lundquist wrote:
On 10 December 2014 at 13:17, Robert White rwh...@pobox.com wrote:
On 12/09/2014 11:19 PM, Patrik Lundquist wrote:
BUT FIRST UNDERSTAND: you do _not_ need to balance a newly converted
filesystem. That is, the recommended balance (and recursive
Robert White posted on Thu, 11 Dec 2014 00:42:38 -0800 as excerpted:
TRUTH BE TOLD :: After two very eventful conversions not too long ago
I just don't do those any more. The total amount of time I saved by
not copying the files was in the negative numbers before I just copied
the files onto
On 11 December 2014 at 09:42, Robert White rwh...@pobox.com wrote:
On 12/10/2014 05:36 AM, Patrik Lundquist wrote:
On 10 December 2014 at 13:17, Robert White rwh...@pobox.com wrote:
On 12/09/2014 11:19 PM, Patrik Lundquist wrote:
BUT FIRST UNDERSTAND: you do _not_ need to balance a newly
So far I don't see a bug.
On 12/11/2014 12:18 AM, Patrik Lundquist wrote:
I'll reboot the thread with a recap and my latest findings.
* Half full 3TB disk converted from ext4 to Btrfs, after first
verifying it with fsck.
* Undo subvolume deleted after being happy with the conversion.
*
On 11 December 2014 at 05:13, Duncan 1i5t5.dun...@cox.net wrote:
Patrik correct me if I have this wrong, but filling in the history as I
believe I have it...
You're right Duncan, except it began as a private question about an
error in a blog and went from there. Not that it matters, except the
On 12/11/2014 01:55 AM, Patrik Lundquist wrote:
On 11 December 2014 at 09:42, Robert White rwh...@pobox.com wrote:
On 12/10/2014 05:36 AM, Patrik Lundquist wrote:
On 10 December 2014 at 13:17, Robert White rwh...@pobox.com wrote:
On 12/09/2014 11:19 PM, Patrik Lundquist wrote:
BUT FIRST
On 11 December 2014 at 11:18, Robert White rwh...@pobox.com wrote:
So far I don't see a bug.
Fair enough, lets call it a huge problem with btrfs convert. I think
it warrants a note in the wiki.
On 12/11/2014 12:18 AM, Patrik Lundquist wrote:
Running defrag several more times and balance
On 12/11/2014 03:01 PM, Patrik Lundquist wrote:
On 11 December 2014 at 11:18, Robert White rwh...@pobox.com wrote:
So far I don't see a bug.
Fair enough, lets call it a huge problem with btrfs convert. I think
it warrants a note in the wiki.
On 12/11/2014 12:18 AM, Patrik Lundquist wrote:
TL;DR version
On 12/11/2014 03:01 PM, Patrik Lundquist wrote:
Of course the filesystem is in a problematic state after the
conversion, even if it's not a bug. ~1.5TB of free space and yet out
of space and it can't be fixed with a balance. It might not be wrong
per se but it's very problematic
On 12/09/2014 11:19 PM, Patrik Lundquist wrote:
On 10 December 2014 at 00:13, Robert White rwh...@pobox.com wrote:
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
Label: none uuid: 770fe01d-6a45-42b9-912e-e8f8b413f6a4
Total devices 1 FS bytes used 1.35TiB
devid1 size 2.73TiB
Robert White posted on Tue, 09 Dec 2014 16:01:02 -0800 as excerpted:
On 12/09/2014 03:48 PM, Robert White wrote:
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
(stuff depicting a nearly full file system).
Having taken another look at it all, I'd bet (there is not sufficient
information to
Robert White posted on Wed, 10 Dec 2014 04:17:50 -0800 as excerpted:
BTRFS info (device sdc1): relocating block group 1821099687936 flags 1
BTRFS error (device sdc1): allocation failed flags 1, wanted 2013265920
BTRFS: space_info 1 has 4773171200 free, is not full BTRFS: space_info
On 10 December 2014 at 13:17, Robert White rwh...@pobox.com wrote:
On 12/09/2014 11:19 PM, Patrik Lundquist wrote:
BUT FIRST UNDERSTAND: you do _not_ need to balance a newly converted
filesystem. That is, the recommended balance (and recursive defrag) is _not_
a useability issue, its an
On 10 December 2014 at 14:11, Duncan 1i5t5.dun...@cox.net wrote:
From there... I've never used it but I /think/ btrfs inspect-internal
logical-resolve should let you map the 182109... address to a filename.
From there, moving that file out of the filesystem and back in should
eliminate that
On 10 December 2014 at 13:47, Duncan 1i5t5.dun...@cox.net wrote:
The recursive btrfs defrag after deleting the saved ext* subvolume
_should_ have split up any such 1 GiB extents so balance could deal
with them, but either it failed for some reason on at least one such
file, or there's some
On 12/10/2014 10:56 AM, Patrik Lundquist wrote:
On 10 December 2014 at 14:11, Duncan 1i5t5.dun...@cox.net wrote:
Assuming no snapshots still contain the file, of course, and that the
ext* saved subvolume has already been deleted.
Got no snapshots or subvolumes. Keeping it simple for now.
Patrik Lundquist posted on Wed, 10 Dec 2014 21:11:52 +0100 as excerpted:
Is btrfs-debug-tree -e useful in finding problematic files?
Since you were replying directly to me, my answer...
ENOTENOUGHINFO
I don't know enough about it to honestly say, as I've never used it
myself and haven't seen
Robert White posted on Wed, 10 Dec 2014 14:28:10 -0800 as excerpted:
On 12/10/2014 10:56 AM, Patrik Lundquist wrote:
On 10 December 2014 at 14:11, Duncan 1i5t5.dun...@cox.net wrote:
Assuming no snapshots still contain the file, of course, and that the
ext* saved subvolume has already been
Patrik Lundquist posted on Wed, 10 Dec 2014 21:11:52 +0100 as excerpted:
Patrik, assuming no btrfs snapshots yet, can you do a du --all --block-
size=1M | sort -n (or similar), then take a look at all results over
1024 (1 GiB since the du specified 1 MiB blocks), and see if it's
reasonable to
On 10 December 2014 at 23:28, Robert White rwh...@pobox.com wrote:
On 12/10/2014 10:56 AM, Patrik Lundquist wrote:
On 10 December 2014 at 14:11, Duncan 1i5t5.dun...@cox.net wrote:
Assuming no snapshots still contain the file, of course, and that the
ext* saved subvolume has already been
On 24 November 2014 at 13:35, Patrik Lundquist
patrik.lundqu...@gmail.com wrote:
On 24 November 2014 at 05:23, Duncan 1i5t5.dun...@cox.net wrote:
Patrik Lundquist posted on Sun, 23 Nov 2014 16:12:54 +0100 as excerpted:
The balance run now finishes without errors with usage=99 and I think
I'll
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
Label: none uuid: 770fe01d-6a45-42b9-912e-e8f8b413f6a4
Total devices 1 FS bytes used 1.35TiB
devid1 size 2.73TiB used 1.36TiB path /dev/sdc1
Data, single: total=1.35TiB, used=1.35TiB
System, single: total=32.00MiB, used=112.00KiB
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
Data, single: total=1.35TiB, used=1.35TiB
System, single: total=32.00MiB, used=112.00KiB
Metadata, single: total=3.00GiB, used=1.55GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
P.S. you should re-balance your System and Metadata as DUP
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
(stuff depicting a nearly full file system).
Having taken another look at it all, I'd bet (there is not sufficient
information to be _sure_ from the output you've provided) that you don't
have the necessary 1Gb free on your disk slice to
On 12/09/2014 03:48 PM, Robert White wrote:
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
(stuff depicting a nearly full file system).
Having taken another look at it all, I'd bet (there is not sufficient
information to be _sure_ from the output you've provided) that you don't
have the
On 10 December 2014 at 00:13, Robert White rwh...@pobox.com wrote:
On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
Label: none uuid: 770fe01d-6a45-42b9-912e-e8f8b413f6a4
Total devices 1 FS bytes used 1.35TiB
devid1 size 2.73TiB used 1.36TiB path /dev/sdc1
Data, single:
On Sun, Nov 23, 2014 at 07:52:29AM +, Duncan wrote:
Right. So, why would you rebalance empty chunks or near empty chunks?
Don't you want to rebalance almost full chunks first, and work you way
to less and less full as needed?
No, the closer to empty a chunk is, the more effect you can
On 2014/11/23 03:07, Marc MERLIN wrote:
On Sun, Nov 23, 2014 at 12:05:04AM +, Hugo Mills wrote:
Which is correct?
Less than or equal to 55% full.
This confuses me. Does that mean that the fullest blocks do not get
rebalanced?
Balance has three primary benefits:
- free up some
On 23 November 2014 at 08:52, Duncan 1i5t5.dun...@cox.net wrote:
[a whole lot]
Thanks for the long post, Duncan.
My venture into the finer details of balance began with converting an
ext4 fs to btrfs and after an inital defrag having a full balance fail
with about a third to go.
Consecutive
On Sun, Nov 23, 2014 at 07:52:29AM +, Duncan wrote:
Right. So, why would you rebalance empty chunks or near empty chunks?
Don't you want to rebalance almost full chunks first, and work you way
to less and less full as needed?
No, the closer to empty a chunk is, the more effect you can
On Sun, 23 Nov 2014 13:16:50 -0800, Marc MERLIN wrote:
(snip)
That makes sense. I'll try to synthetize all this and rewrite my blog
post and the wiki to make this clearer.
Maybe also add that as of 3.18 empty block groups are automatically
collected, so balancing to prevent
Patrik Lundquist posted on Sun, 23 Nov 2014 16:12:54 +0100 as excerpted:
The balance run now finishes without errors with usage=99 and I think
I'll leave it at that. No RAID yet but will convert to RAID1.
Converting between raid modes is done with a balance, so if you can't get
that last bit
Holger Hoffstätte posted on Sun, 23 Nov 2014 22:49:01 + as excerpted:
On Sun, 23 Nov 2014 13:16:50 -0800, Marc MERLIN wrote:
(snip)
That makes sense. I'll try to synthetize all this and rewrite my blog
post and the wiki to make this clearer.
Maybe also add that as of 3.18 empty
+btrfs list so that someone can correct me if I'm wrong.
On Sat, Nov 22, 2014 at 09:34:59PM +0100, Patrik Lundquist wrote:
Hi,
I was scratching my head over a failing btrfs balance and read your
very informative
On 22 November 2014 at 23:26, Marc MERLIN m...@merlins.org wrote:
This one hurts my brain every time I think about it :)
I'm new to Btrfs so I may very well be wrong, since I haven't really
read up on it. :-)
So, the bigger the -dusage number, the more work btrfs has to do.
Agreed.
On Sun, Nov 23, 2014 at 12:26:38AM +0100, Patrik Lundquist wrote:
I realize that I interpret the usage parameter as operating on blocks
(chunks? are they the same in this case?) that are = 55% full while
you interpret it as = 55% free.
Which is correct?
I will let someone else answer
On Sun, Nov 23, 2014 at 12:26:38AM +0100, Patrik Lundquist wrote:
On 22 November 2014 at 23:26, Marc MERLIN m...@merlins.org wrote:
This one hurts my brain every time I think about it :)
I'm new to Btrfs so I may very well be wrong, since I haven't really
read up on it. :-)
So, the
On Sun, Nov 23, 2014 at 12:05:04AM +, Hugo Mills wrote:
Which is correct?
Less than or equal to 55% full.
This confuses me. Does that mean that the fullest blocks do not get
rebalanced?
I guess I was under the mistaken impression that the more data you had the
more you could be out
Marc MERLIN posted on Sat, 22 Nov 2014 17:07:42 -0800 as excerpted:
On Sun, Nov 23, 2014 at 12:05:04AM +, Hugo Mills wrote:
Which is correct?
Less than or equal to 55% full.
This confuses me. Does that mean that the fullest blocks do not get
rebalanced?
Yes. =:^)
I guess I
40 matches
Mail list logo
