errno=-28 No space left, with kernel backtrace (blocking bug)

errno=-28 No space left, with kernel backtrace (blocking bug)

[alpha_one_x86]

Hi, this bug is very blocking for me:

https://bugzilla.kernel.org/show_bug.cgi?id=195257

The server is backup server, I btrfs receive (with and without -p), and
of course btrfs subvolume delete
The volume is 70TB, then I use space_cache=v2

Cheers,


-- 
alpha_one_x86/BRULE Herman <alpha_one_x86@first-world.info>
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management
IT, OS, technologies, research & development, security and business department

Re: errno=-28 No space left, with kernel backtrace (blocking bug)

[alpha_one_x86]

Up plz, I can work with this bug.


On 05/11/17 01:39, alpha_one_x86 wrote:
> Hi, this bug is very blocking for me:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=195257
>
> The server is backup server, I btrfs receive (with and without -p), and
> of course btrfs subvolume delete
> The volume is 70TB, then I use space_cache=v2
>
> Cheers,
>
>

-- 
alpha_one_x86/BRULE Herman <alpha_one_x86@first-world.info>
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management
IT, OS, technologies, research & development, security and business department

Re: errno=-28 No space left, with kernel backtrace (blocking bug)

[Duncan]

alpha_one_x86 posted on Thu, 11 May 2017 17:25:32 +0200 as excerpted:

> Up plz, I can work with this bug.
> 
> 
> On 05/11/17 01:39, alpha_one_x86 wrote:
>> Hi, this bug is very blocking for me:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=195257
>>
>> The server is backup server, I btrfs receive (with and without -p), and
>> of course btrfs subvolume delete The volume is 70TB, then I use
>> space_cache=v2

Since you can work with it, do so.  We're not stopping you. =:^)

Or did you mean /can't/?

Keep in mind that while btrfs is considered stabilizing, on this list at 
least it's not considered fully stable and mature.  If you want/need a 
filesystem that's stable and mature, there's others out there that fill 
that requirement.  We don't claim btrfs does.  Your system, your choice 
of filesystem and with it, filesystem maturity.

Meanwhile, btrfs devs have a lot of stuff on their plate, including bugs 
they're already working on and further development, and (as with most 
devs) aren't going to take kindly to demands that they work on *YOUR* bug 
*RIGHT* *NOW*.  That, if anything, is about the fastest way I know of to 
ensure that working on it is /deprioritized/, with stuff that would have 
been put off to work on it, done first, instead.

Unless of course you're paying the salary of that dev.  If you are, then 
you get to call the shots, to some degree at least.  Good devs tend to 
find other employment if you're too controlling, tho, and they can 
because good devs are in enough demand they often pick their jobs from a 
list of offers, and they tend to be motivated by more than money so if 
you're too demanding you can't expect to simply outbid everyone else on 
the list, either, no matter how much money you have.  And any dev skilled 
enough to regularly get their work into the mainline kernel can be 
considered a good dev, so...

So I'd suggest that if it's high enough priority to you, you'll find a 
kernel dev and sponsor them to work on it for you.  But be warned, if 
they're not already a btrfs dev, it'll take them some time to come upto 
speed.  Otherwise, you'll wait in line with everyone else... unless you 
push too much, in which case your reports will as I said get 
deprioritized, and if noone else reports them, your bugs may not get 
handled until there's nothing else waiting... which could easily push 
resolution past 2027... yes, a decade or more out.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: errno=-28 No space left, with kernel backtrace (blocking bug)

[alpha_one_x86]

Hi.

I wish mean: I can't.

I now for the btrfs maturity. But it's my unique alternative.

I understand. For me this bug should be important because it block all
the system, since Linux 4.1+

It's exactly what I wish, pay to have a quick fix. I don't think I wish
too much, just fix this bug and put to upstream.

Thanks for your time to read me, and thanks for confirm this bug is not
forget. A least somebody have take time to read me, great thanks for this.

Cheers,


On 05/12/17 04:01, Duncan wrote:
> alpha_one_x86 posted on Thu, 11 May 2017 17:25:32 +0200 as excerpted:
>
>> Up plz, I can work with this bug.
>>
>>
>> On 05/11/17 01:39, alpha_one_x86 wrote:
>>> Hi, this bug is very blocking for me:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=195257
>>>
>>> The server is backup server, I btrfs receive (with and without -p), and
>>> of course btrfs subvolume delete The volume is 70TB, then I use
>>> space_cache=v2
> Since you can work with it, do so.  We're not stopping you. =:^)
>
> Or did you mean /can't/?
>
> Keep in mind that while btrfs is considered stabilizing, on this list at 
> least it's not considered fully stable and mature.  If you want/need a 
> filesystem that's stable and mature, there's others out there that fill 
> that requirement.  We don't claim btrfs does.  Your system, your choice 
> of filesystem and with it, filesystem maturity.
>
> Meanwhile, btrfs devs have a lot of stuff on their plate, including bugs 
> they're already working on and further development, and (as with most 
> devs) aren't going to take kindly to demands that they work on *YOUR* bug 
> *RIGHT* *NOW*.  That, if anything, is about the fastest way I know of to 
> ensure that working on it is /deprioritized/, with stuff that would have 
> been put off to work on it, done first, instead.
>
> Unless of course you're paying the salary of that dev.  If you are, then 
> you get to call the shots, to some degree at least.  Good devs tend to 
> find other employment if you're too controlling, tho, and they can 
> because good devs are in enough demand they often pick their jobs from a 
> list of offers, and they tend to be motivated by more than money so if 
> you're too demanding you can't expect to simply outbid everyone else on 
> the list, either, no matter how much money you have.  And any dev skilled 
> enough to regularly get their work into the mainline kernel can be 
> considered a good dev, so...
>
> So I'd suggest that if it's high enough priority to you, you'll find a 
> kernel dev and sponsor them to work on it for you.  But be warned, if 
> they're not already a btrfs dev, it'll take them some time to come upto 
> speed.  Otherwise, you'll wait in line with everyone else... unless you 
> push too much, in which case your reports will as I said get 
> deprioritized, and if noone else reports them, your bugs may not get 
> handled until there's nothing else waiting... which could easily push 
> resolution past 2027... yes, a decade or more out.
>

-- 
alpha_one_x86/BRULE Herman <alpha_one_x86@first-world.info>
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management
IT, OS, technologies, research & development, security and business department