Martin Steigerwald posted on Thu, 08 Jan 2015 11:18:40 +0100 as excerpted:
Duncan, I *did* file a bug.
I think you misunderstood me... I understood that and actually said as
much:
But the recommendation is to file the bugzilla report precisely so it
does /not/ get lost, and you've done
Am Freitag, 9. Januar 2015, 11:04:32 schrieb Peter Waller:
Apologies to those receiving this twice.
On 27 December 2014 at 09:30, Hugo Mills h...@carfax.org.uk wrote:
Now, since you're seeing lockups when the space on your disks is
all allocated I'd say that's a bug. However, you're the
Apologies to those receiving this twice.
On 27 December 2014 at 09:30, Hugo Mills h...@carfax.org.uk wrote:
Now, since you're seeing lockups when the space on your disks is
all allocated I'd say that's a bug. However, you're the *only* person
who's reported this as a regular occurrence.
Am Donnerstag, 8. Januar 2015, 05:45:56 schrieben Sie:
Martin Steigerwald posted on Wed, 07 Jan 2015 20:08:50 +0100 as excerpted:
No BTRFS developers commented yet on this, neither in this thread nor in
the bug report at kernel.org I made.
Just a quick general note on this point...
Martin Steigerwald posted on Wed, 07 Jan 2015 20:08:50 +0100 as excerpted:
No BTRFS developers commented yet on this, neither in this thread nor in
the bug report at kernel.org I made.
Just a quick general note on this point...
There has in the past (and I believe referenced on the wiki) been
On Wed, Jan 07, 2015 at 08:08:50PM +0100, Martin Steigerwald wrote:
Am Dienstag, 6. Januar 2015, 15:03:23 schrieb Zygo Blaxell:
ext3 has a related problem when it's nearly full: it will try to search
gigabytes of block allocation bitmaps searching for a free block, which
can result in a
Am Dienstag, 6. Januar 2015, 15:03:23 schrieb Zygo Blaxell:
On Mon, Dec 29, 2014 at 10:32:00AM +0100, Martin Steigerwald wrote:
Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell:
On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
[…]
Zygo, was is the
Am Sonntag, 28. Dezember 2014, 16:27:41 schrieb Robert White:
On 12/28/2014 07:42 AM, Martin Steigerwald wrote:
Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
Summarized at
Am Sonntag, 28. Dezember 2014, 21:07:05 schrieb Zygo Blaxell:
On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
My simple test case didn´t trigger it, and I so not have another twice 160
GiB available on this SSDs available to try with a copy of my home
filesystem. Then I
Am Sonntag, 28. Dezember 2014, 18:04:31 schrieb Patrik Lundquist:
On 28 December 2014 at 13:03, Martin Steigerwald mar...@lichtvoll.de wrote:
BTW, I found that the Oracle blog didn´t work at all for me. I completed
a cycle of defrag, sdelete -c and VBoxManage compact, [...] and it
Am Samstag, 27. Dezember 2014, 16:06:13 schrieb Robert White:
I also don't know what kind of tool you are using, but it might be
repeatedly trying and failing to fallocate the file as a single
extent or something equally dumb.
Userspace doesn't as far as I know, get to make that
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
On 12/27/2014 05:01 PM, Bardur Arantsson wrote:
On 2014-12-28 01:25, Robert White wrote:
On 12/27/2014 08:01 AM, Martin Steigerwald wrote:
From how you write I get the impression that you think everyone else
beside you is just
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Now:
The complaining party has verified the minimum, repeatable case of
simple file allocation on a very fragmented system and the responding
party and several others have understood and supported the bug.
I didn´t yet provide
Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
Summarized at
Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for
minutes on random write into big file
https://bugzilla.kernel.org/show_bug.cgi?id=90401
see below. This is reproducable with fio, no
Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
Summarized at
Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for
minutes on random write into big file
Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
Summarized at
Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core
On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Now:
The complaining party has verified the minimum, repeatable case of
simple file allocation on a very fragmented system and the responding
party and several others have understood
Am Sonntag, 28. Dezember 2014, 14:56:21 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 14:40:32 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 14:00:19 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 14:55:58 schrieb Martin Steigerwald:
Summarized at
Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Now:
The complaining party has verified the minimum, repeatable case of
simple file allocation on a very
Am Sonntag, 28. Dezember 2014, 16:42:20 schrieb Martin Steigerwald:
Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Now:
The complaining party has verified
On 28 December 2014 at 13:03, Martin Steigerwald mar...@lichtvoll.de wrote:
BTW, I found that the Oracle blog didn´t work at all for me. I completed
a cycle of defrag, sdelete -c and VBoxManage compact, [...] and it
apparently did *nothing* to reduce the size of the file.
They've changed the
On 12/28/2014 07:42 AM, Martin Steigerwald wrote:
Am Sonntag, 28. Dezember 2014, 06:52:41 schrieb Robert White:
On 12/28/2014 04:07 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 20:03:09 schrieb Robert White:
Now:
The complaining party has verified the minimum, repeatable case
On Sat, Dec 27, 2014 at 08:23:59PM +0100, Martin Steigerwald wrote:
My simple test case didn´t trigger it, and I so not have another twice 160
GiB available on this SSDs available to try with a copy of my home
filesystem. Then I could safely test without bringing the desktop session to
an
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
Hello!
First: Have a merry christmas and enjoy a quiet time in these days.
Second: At a time you feel like it, here is a little rant, but also a bug
report:
I have
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
Hello!
First: Have a merry christmas and enjoy a quiet time in these days.
Second: At a time you
Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills:
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
Hello!
First: Have a merry christmas
Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills:
I only see the lockups of BTRFS is the trees *occupy* all space on the
device.
No, the trees occupy 3.29 GiB of your 5 GiB of mirrored metadata
space. What's more, balance does *not* balance the metadata trees. The
On 12/27/2014 02:54 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills:
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
On 12/27/2014 03:11 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 09:30:43 schrieb Hugo Mills:
I only see the lockups of BTRFS is the trees *occupy* all space on the
device.
No, the trees occupy 3.29 GiB of your 5 GiB of mirrored metadata
space. What's more, balance does
Am Samstag, 27. Dezember 2014, 03:52:56 schrieb Robert White:
My theory from watching the Windows XP defragmentation case is this:
- For writing into the file BTRFS needs to actually allocate and use free
space in the current tree allocation, or, as we seem to misunderstood
from the
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 03:52:56 schrieb Robert White:
My theory from watching the Windows XP defragmentation case is this:
- For writing into the file BTRFS needs to actually allocate and use free
space in the current tree allocation,
Summarized at
Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for minutes
on random write into big file
https://bugzilla.kernel.org/show_bug.cgi?id=90401
see below. This is reproducable with fio, no need for Windows XP in
Virtualbox for reproducing the issue. Next I will try
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
It can easily be reproduced without even using Virtualbox, just by a nice
simple fio job.
TL;DR: If you want a worst-case example of consuming a BTRFS filesystem
with one single file...
#!/bin/bash
# not tested, so correct any syntax errors
Am Samstag, 27. Dezember 2014, 05:49:48 schrieb Robert White:
Anyway, I got it reproduced. And am about to write a lengthy mail about.
Have fun with that lengthy email, but the devs already know about the
data waste profile of the system. They just don't have a good solution yet.
Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White:
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
It can easily be reproduced without even using Virtualbox, just by a nice
simple fio job.
TL;DR: If you want a worst-case example of consuming a BTRFS filesystem
with one single
On 12/27/2014 06:00 AM, Robert White wrote:
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
It can easily be reproduced without even using Virtualbox, just by a nice
simple fio job.
TL;DR: If you want a worst-case example of consuming a BTRFS filesystem
with one single file...
#!/bin/bash
Am Samstag, 27. Dezember 2014, 15:14:05 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White:
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
It can easily be reproduced without even using Virtualbox, just by a
nice
simple fio job.
TL;DR: If
On 12/27/2014 05:55 AM, Martin Steigerwald wrote:
Summarized at
Bug 90401 - btrfs kworker thread uses up 100% of a Sandybridge core for minutes
on random write into big file
https://bugzilla.kernel.org/show_bug.cgi?id=90401
see below. This is reproducable with fio, no need for Windows XP in
On 12/27/2014 06:21 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 15:14:05 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White:
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
It can easily be reproduced without even using Virtualbox, just
Am Samstag, 27. Dezember 2014, 07:14:32 schrieb Robert White:
But yes, if you open a file and scribble all over it when your disk is
full to within the same order of magnitude as the size of the file you
are scribbling on, you will get into a condition where the _application_
will
Am Samstag, 27. Dezember 2014, 07:14:32 schrieb Robert White:
On 12/27/2014 06:21 AM, Martin Steigerwald wrote:
Am Samstag, 27. Dezember 2014, 15:14:05 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 06:00:48 schrieb Robert White:
On 12/27/2014 05:16 AM, Martin Steigerwald wrote:
On Sat, Dec 27, 2014 at 06:54:33AM -0800, Robert White wrote:
On 12/27/2014 05:55 AM, Martin Steigerwald wrote:
[snip]
while fio was just *laying* out the 4 GiB file. Yes, thats 100% system CPU
for 10 seconds while allocatiing a 4 GiB file on a filesystem like:
martin@merkaba:~ LANG=C df -hT
Am Samstag, 27. Dezember 2014, 16:26:42 schrieb Hugo Mills:
On Sat, Dec 27, 2014 at 06:54:33AM -0800, Robert White wrote:
On 12/27/2014 05:55 AM, Martin Steigerwald wrote:
[snip]
while fio was just *laying* out the 4 GiB file. Yes, thats 100% system CPU
for 10 seconds while allocatiing a 4
Am Samstag, 27. Dezember 2014, 18:11:21 schrieb Martin Steigerwald:
Am Samstag, 27. Dezember 2014, 16:26:42 schrieb Hugo Mills:
On Sat, Dec 27, 2014 at 06:54:33AM -0800, Robert White wrote:
On 12/27/2014 05:55 AM, Martin Steigerwald wrote:
[snip]
while fio was just *laying* out the 4
On Sat, Dec 27, 2014 at 09:30:43AM +, Hugo Mills wrote:
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
Now, since you're seeing lockups when the space
On Sat, Dec 27, 2014 at 01:28:46PM -0500, Zygo Blaxell wrote:
On Sat, Dec 27, 2014 at 09:30:43AM +, Hugo Mills wrote:
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014, 14:48:38 schrieb Robert White:
On 12/26/2014 05:37 AM, Martin
Am Samstag, 27. Dezember 2014, 18:40:17 schrieb Hugo Mills:
On Sat, Dec 27, 2014 at 01:28:46PM -0500, Zygo Blaxell wrote:
On Sat, Dec 27, 2014 at 09:30:43AM +, Hugo Mills wrote:
On Sat, Dec 27, 2014 at 10:01:17AM +0100, Martin Steigerwald wrote:
Am Freitag, 26. Dezember 2014,
Semi off-topic questions...
On 12/27/2014 08:26 AM, Hugo Mills wrote:
This is... badly mistaken, at best. The problem of where to write a
file into a set of free extents is definitely *not* an NP-hard
problem. It's a P problem, with an O(n log n) solution, where n is the
number of free
On 12/27/2014 08:01 AM, Martin Steigerwald wrote:
From how you write I get the impression that you think everyone else
beside you is just silly and dumb. Please stop this assumption. I may not
always get terms right, and I may make a mistake as with the wrong df
figure. But I also highly
On 2014-12-28 01:25, Robert White wrote:
On 12/27/2014 08:01 AM, Martin Steigerwald wrote:
From how you write I get the impression that you think everyone else
beside you is just silly and dumb. Please stop this assumption. I may not
always get terms right, and I may make a mistake as with the
On 12/27/2014 05:01 PM, Bardur Arantsson wrote:
On 2014-12-28 01:25, Robert White wrote:
On 12/27/2014 08:01 AM, Martin Steigerwald wrote:
From how you write I get the impression that you think everyone else
beside you is just silly and dumb. Please stop this assumption. I may not
always get
Hello!
First: Have a merry christmas and enjoy a quiet time in these days.
Second: At a time you feel like it, here is a little rant, but also a bug
report:
I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with
space_cache, skinny meta data extents –
Am Freitag, 26. Dezember 2014, 14:37:36 schrieben Sie:
It currently is here:
merkaba:~ btrfs balance status /home
Balance on '/home' is running
32 out of about 164 chunks balanced (53 considered), 80% left
merkaba:~ btrfs fi df /home
Data, RAID1: total=154.97GiB, used=142.10GiB
System,
Am Freitag, 26. Dezember 2014, 15:20:42 schrieben Sie:
And I wonder about:
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599
84C7N�r��yb�X��ǧv�^�){.n�+{�n�߲)w* jg��� �ݢj/���z�ޖ��2
�ޙ�)ߡ�a����
Am Freitag, 26. Dezember 2014, 14:37:36 schrieben Sie:
I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with
space_cache, skinny meta data extents – are these a problem? – and
compress=lzo:
merkaba:~ btrfs fi sh /home
Label: 'home' uuid:
On 12/26/2014 05:37 AM, Martin Steigerwald wrote:
Hello!
First: Have a merry christmas and enjoy a quiet time in these days.
Second: At a time you feel like it, here is a little rant, but also a bug
report:
I have this on 3.18 kernel on Debian Sid with BTRFS Dual SSD RAID with
space_cache,
Martin Steigerwald posted on Fri, 26 Dec 2014 15:41:23 +0100 as excerpted:
Am Freitag, 26. Dezember 2014, 15:20:42 schrieben Sie:
And I wonder about:
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C
0040 0710 4AFA B82F 991B EAAC A599
Martin Steigerwald posted on Fri, 26 Dec 2014 16:59:09 +0100 as excerpted:
Dec 26 16:17:57 merkaba kernel: [ 8102.029438] mce:
[Hardware Error]: Machine check events logged
Dec 26 16:20:27 merkaba kernel: [ 8252.054015] mce:
[Hardware Error]: Machine check events logged
Have you checked
Robert White posted on Fri, 26 Dec 2014 14:48:38 -0800 as excerpted:
ITEM: An SSD plus a good fast controller and default system virtual
memory and disk scheduler activities can completely bog a system down.
You can get into a mode where the system begins doing synchronous writes
of vast
60 matches
Mail list logo
