On Sat, Feb 27, 2016 at 10:14:50PM +0100, Marc Haber wrote:
> I have again the issue of no space left on device while rebalancing
> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
just for the record: The host started acting up in more and more
interesting ways, and after a call of
Martin Steigerwald posted on Sun, 27 Mar 2016 14:10:07 +0200 as excerpted:
> On Freitag, 4. März 2016 12:31:44 CEST Duncan wrote:
>> Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
>> > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>> >> You're issue isn't the
On Sun, Mar 13, 2016 at 2:50 PM, Marc Haber wrote:
> On Sun, Mar 13, 2016 at 01:43:50PM -0600, Chris Murphy wrote:
>> On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
>> wrote:
>> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy
On Sun, Mar 13, 2016 at 01:43:50PM -0600, Chris Murphy wrote:
> On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
> wrote:
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> Something is happening with the usage of this file system that's out
> >> of
On Sat, Mar 12, 2016 at 12:57 PM, Marc Haber
wrote:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> Something is happening with the usage of this file system that's out
>> of the ordinary. This is the first time I've seen such a large amount
>> of
On Mon, Mar 07, 2016 at 11:39:11AM -0700, Chris Murphy wrote:
> Since there's no hardware issue suspect, you could filter for just btrfs.
>
> journalctl -o short-iso | grep -i btrfs
Which is exactly what I did. Why did you suspect that my logs were
"trimmed"? That's what got me kind of furious.
On Sun, Mar 06, 2016 at 01:27:10PM -0700, Chris Murphy wrote:
> So if it were me, I'd gather all possible data, including complete,
> not trimmed, logs. And as for the btrfs-image, it could be huge.
[5/504]mh@q:~/.www/public_html/stuff$ unxz --list 20160307-fanbtr-image.xz
Strms Blocks
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> I'd try to use -musage filter alone, in whatever increments work. So
> try 0. Then 5. If 5 fails, try 2. Increment until size is not much
> more than 2-3x used.
Here we go:
[7/506]mh@fan:~$ sudo btrfs balance -usage=0
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> Something is happening with the usage of this file system that's out
> of the ordinary. This is the first time I've seen such a large amount
> of unused metadata allocation. And then for it not only fail to
> balance, but for the
On Mon, Mar 7, 2016 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Mon, 07 Mar 2016 12:44:20 -0700 as excerpted:
>
>> On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber
>> wrote:
>>> And this is really something to be proud of? I mean, this is a
Chris Murphy posted on Mon, 07 Mar 2016 12:44:20 -0700 as excerpted:
> On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber
> wrote:
>> And this is really something to be proud of? I mean, this is a file
>> system that is part of the vanilla linux kernel, not marked as
>>
Marc Haber posted on Mon, 07 Mar 2016 09:30:43 +0100 as excerpted:
> I have dug aroud in my auth.logs, and thanks to my not working in a root
> shell but using sudo for every single command I can say that the
> filesystem was created on September 1, 2015, so it is not _this_ old,
> and
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
> And this is really something to be proud of? I mean, this is a file
> system that is part of the vanilla linux kernel, not marked as
> experimental or something, and you're still concerned about file
> systems that
On Mon, Mar 07, 2016 at 01:56:54PM -0500, Austin S. Hemmelgarn wrote:
> Yeah, in general, if you want to get good upstream support for BTRFS (such
> as from the mailing lists), you still want to steer clear of 'Enterprise'
> branded distros (RHEL (and by extension CentOS) is particularly bad about
On Mon, Mar 7, 2016 at 11:56 AM, Austin S. Hemmelgarn
wrote:
> People don't often think about it, but given the degree of code and
> version divergence due to patches, RHEL, SLES, and OEL kernels are strictly
> speaking, forks of Linux (most distro kernels are, but usually
On 2016-03-07 13:39, Chris Murphy wrote:
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
[1] Does RHEL 6 have btrfs in the first place?
They do, but you need a decoder ring to figure out what's been
backported to have some vague idea of what equivalent
On Mon, Mar 7, 2016 at 1:42 AM, Marc Haber wrote:
> On Sun, Mar 06, 2016 at 01:27:10PM -0700, Chris Murphy wrote:
>> On the one hand, the practical advice is to just blow it away and use
>> everything current, go back to the same workload including thousands
>> of
On Sat, Mar 05, 2016 at 09:09:09PM +0100, Marc Haber wrote:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> > So understanding the usage is important to figuring out what's
> > happening. I'd file a bug and include as much information on how the
> > fs got into this state as
On Sun, Mar 06, 2016 at 01:37:31PM -0700, Chris Murphy wrote:
> On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy wrote:
> > So if it were me, I'd gather all possible data, including complete,
> > not trimmed, logs.
>
> Also include in the bug, the balance script being used.
On Sun, Mar 06, 2016 at 01:27:10PM -0700, Chris Murphy wrote:
> Marc said it was created maybe 2 years ago and doesn't remember what
> version of the tools were used. Between it being two years ago and
> also being Debian, for all we know it could've been 0.19. *shrug*
You are mixing up Debian
On Sun, Mar 06, 2016 at 06:43:46AM +, Duncan wrote:
> Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
> > On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> >> Something is happening with the usage of this file system that's out of
> >> the ordinary. This is the
On Sun, Mar 6, 2016 at 1:27 PM, Chris Murphy wrote:
> So if it were me, I'd gather all possible data, including complete,
> not trimmed, logs.
Also include in the bug, the balance script being used. It might be a
contributing factor.
I wonder if the ENOSPC is happening
On Sat, Mar 5, 2016 at 11:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
>
>> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>
>>> Something is happening with the usage of this file system that's out of
>>> the
Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> Something is happening with the usage of this file system that's out of
>> the ordinary. This is the first time I've seen such a large amount of
>> unused
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> I can't tell what this btrfs-balance script is doing because not every
> btrfs balance command is in the log.
It is. I wrote it to produce reproducible logs.
[1/499]mh@fan:~$ cat btrfs-balance
#!/bin/bash
FS="/mnt/fanbtr"
showdf()
I can't tell what this btrfs-balance script is doing because not every
btrfs balance command is in the log. It may be doing something not
advisable or suboptimal or unexpected that along with some other bug
is causing this to happen
Metadata,DUP: Size:107.00GiB, Used:2.11GiB
I'd try to use
On Thu, Mar 03, 2016 at 02:28:36AM +0200, Dāvis Mosāns wrote:
> I've same issue, 4.4.3 kernel on Arch Linux
>
> $ sudo btrfs fi show /mnt/fs/
> Label: 'fs' uuid: a3c66d25-2c25-40e5-a827-5f7e5208e235
> Total devices 1 FS bytes used 396.94GiB
> devid1 size 435.76GiB used
Hi,
I have not seen this message coming back to the mailing list. Was it
again too long?
I have pastebinned the log at http://paste.debian.net/412118/
On Tue, Mar 01, 2016 at 08:51:32PM +, Duncan wrote:
> There has been something bothering me about this thread that I wasn't
> quite pinning
On Fri, Mar 04, 2016 at 12:31:44PM +, Duncan wrote:
> Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
>
> > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
> >>
> >> You're issue isn't the same, because all your space was allocated,
> >> leaving only 1 MiB
Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
> 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>>
>> You're issue isn't the same, because all your space was allocated,
>> leaving only 1 MiB unallocated, which isn't normally enough to allocate
>> a new chunk to
2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>
> You're issue isn't the same, because all your space was allocated,
> leaving only 1 MiB unallocated, which isn't normally enough to allocate a
> new chunk to rewrite the data or metadata from the old chunks into.
>
> That's a known
Dāvis Mosāns posted on Thu, 03 Mar 2016 02:28:36 +0200 as excerpted:
> 2016-02-27 23:14 GMT+02:00 Marc Haber :
>> Hi,
>>
>> I have again the issue of no space left on device while rebalancing
>> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
>>
>>
> I've
Dāvis Mosāns wrote on 2016/03/03 02:28 +0200:
2016-02-27 23:14 GMT+02:00 Marc Haber :
Hi,
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
I've same issue, 4.4.3 kernel on Arch
Thanks for the output.
At least for mprofile enospc error, the problem itself is very
straightforward, just unable to alloc tree block.
I'll check the codes to see if we can improve it, by finding out why we
can't alloc a new chunk to resolve the problem.
But I'm still a little concerned
2016-02-27 23:14 GMT+02:00 Marc Haber :
> Hi,
>
> I have again the issue of no space left on device while rebalancing
> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
>
I've same issue, 4.4.3 kernel on Arch Linux
$ sudo btrfs fi show /mnt/fs/
Label:
Qu Wenruo posted on Tue, 01 Mar 2016 15:24:03 +0800 as excerpted:
>
> Marc Haber wrote on 2016/03/01 07:54 +0100:
>> On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
>>> Didn't see the attachment though, seems to be filtered by maillist
>>> police.
>>
>> Trying again.
>
> OK, I got
Qu Wenruo wrote on 2016/03/01 15:24 +0800:
Marc Haber wrote on 2016/03/01 07:54 +0100:
On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
Didn't see the attachment though, seems to be filtered by maillist
police.
Trying again.
OK, I got the attachment.
And, surprisingly, btrfs
Marc Haber wrote on 2016/03/01 07:54 +0100:
On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
Didn't see the attachment though, seems to be filtered by maillist police.
Trying again.
OK, I got the attachment.
And, surprisingly, btrfs balance on data chunk works without problem,
Marc Haber wrote on 2016/02/29 16:33 +0100:
Hi,
On Mon, Feb 29, 2016 at 09:56:58AM +0800, Qu Wenruo wrote:
Marc Haber wrote on 2016/02/27 22:14 +0100:
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
mh@fan:~$
Hi,
On Mon, Feb 29, 2016 at 09:56:58AM +0800, Qu Wenruo wrote:
> Marc Haber wrote on 2016/02/27 22:14 +0100:
> >I have again the issue of no space left on device while rebalancing
> >(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
> >
> >mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
Marc Haber wrote on 2016/02/27 22:14 +0100:
Hi,
I have again the issue of no space left on device while rebalancing
(with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
ERROR: error during balancing '/mnt/fanbtr': No space left on device
On Sun, Feb 28, 2016 at 12:22:45AM +, Hugo Mills wrote:
> On Sun, Feb 28, 2016 at 01:08:29AM +0100, Marc Haber wrote:
> > Why wouldn't btrfs allocate more data chunks from the ample free space?
>
>It's a bug. It's been around for years (literally), but nobody's
> tracked it down and fixed
On Sun, Feb 28, 2016 at 01:08:29AM +0100, Marc Haber wrote:
> On Sun, Feb 28, 2016 at 12:15:21AM +0100, Martin Steigerwald wrote:
> > On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> > > I have again the issue of no space left on device while rebalancing
> > > (with btrfs-tools 4.4.1
On Sun, Feb 28, 2016 at 12:15:21AM +0100, Martin Steigerwald wrote:
> On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> > I have again the issue of no space left on device while rebalancing
> > (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
> >
> > mh@fan:~$ sudo btrfs
On Samstag, 27. Februar 2016 22:14:50 CET Marc Haber wrote:
> Hi,
Hi Marc.
> I have again the issue of no space left on device while rebalancing
> (with btrfs-tools 4.4.1 on kernel 4.4.2 on Debian unstable):
>
> mh@fan:~$ sudo btrfs balance start /mnt/fanbtr
> ERROR: error during balancing
45 matches
Mail list logo