Hello
The problem:
Every time I start my browser, file system is remounted in read-only
mode.
The cause:
I believe the problem originates from hard reset I had to do.
The details:
# uname -a
Linux tamuz 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014
x86_64
GNU/Linux
# btrfs
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
Hello Satoru and all,
that Oct. report was the only time I've experienced the error, so I
don't have much to add. I can try to answer your questions:
Here are my questions.
1. Is your system btrfs scrub clean?
yes,
2. Is this message shown every boot time?
no, I have seen them only
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 Fri, Dec 26, 2014 at 1:43 PM, Satoru Takeuchi
takeuchi_sat...@jp.fujitsu.com wrote:
Hi Yang,
On 2014/12/26 10:32, Dongsheng Yang wrote:
Hi Satoru,
I saw your mail of [BUG] Quota Ignored On write problem still exist
with 3.16-rc5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/23/2014 05:09 PM, Chris Murphy wrote:
The timer in /sys is a kernel command timer, it's not a device
timer even though it's pointed at a block device. You need to
change that from 30 to something higher to get the behavior you
want. It
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
32 matches
Mail list logo
