I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
[ 1121.983975] BTRFS: device fsid 8cc641f9-563a-4d62-9157-9503156ce62c devid 1
transid 4 /dev/sdc5
[ 1121.987994] BTRFS info (device sdc5): disk space caching is enabled
[ 1121.987999] BTRFS: flagging fs
On Sun, 15 Jun 2014 18:47:39 -0700, Marc MERLIN wrote:
On Mon, Jun 16, 2014 at 09:35:23AM +0800, Wang Shilong wrote:
On 06/15/2014 12:05 AM, Marc MERLIN wrote:
Taking snapshots is now output this in addition of the snapshot
operation.
Transaction commit: none (default)
1) Is that
On 06/16/2014 03:06 PM, Holger Hoffstätte wrote:
On Sun, 15 Jun 2014 18:47:39 -0700, Marc MERLIN wrote:
On Mon, Jun 16, 2014 at 09:35:23AM +0800, Wang Shilong wrote:
On 06/15/2014 12:05 AM, Marc MERLIN wrote:
Taking snapshots is now output this in addition of the snapshot
operation.
Hi,
I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I
know...], and I noticed that the FS got created with metadata in DUP mode,
contrary to what man mkfs.btrfs says for SSDs - it would be supposed to be
SINGLE...
Well I don't know if my system didn't identify the
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily supposed to write anything really, it's
mostly about
On Mon, 16 Jun 2014 12:14:49 Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't
On 2014-06-16 03:54, Swâmi Petaramesh wrote:
Hi,
I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I
know...], and I noticed that the FS got created with metadata in DUP mode,
contrary to what man mkfs.btrfs says for SSDs - it would be supposed to be
SINGLE...
On 2014-06-16 06:35, Russell Coker wrote:
On Mon, 16 Jun 2014 12:14:49 Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour.
Hi Austin, and thanks for your reply.
Le lundi 16 juin 2014, 07:09:55 Austin S Hemmelgarn a écrit :
What mkfs.btrfs looks at is
/sys/block/whatever-device/queue/rotational, if that is 1 it knows
that the device isn't a SSD. I believe that LVM passes through whatever
the next lower layer's
The lock_wq wait queue is not used anywhere, therefore just remove it.
On a x86_64 system, this reduced sizeof(struct extent_buffer) from 320
bytes down to 296 bytes, which means a 4Kb page can now be used for
13 extent buffers instead of 12.
Signed-off-by: Filipe David Borba Manana
On 2014-06-16 07:18, Swâmi Petaramesh wrote:
Hi Austin, and thanks for your reply.
Le lundi 16 juin 2014, 07:09:55 Austin S Hemmelgarn a écrit :
What mkfs.btrfs looks at is
/sys/block/whatever-device/queue/rotational, if that is 1 it knows
that the device isn't a SSD. I believe that LVM
On Mon, Jun 16, 2014 at 2:14 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
On Mon, 16 Jun 2014 07:23:14 Austin S Hemmelgarn wrote:
I'd personally stay with the DUP profile, but then that's just me being
paranoid. You will almost certainly get better performance using the
SINGLE profile instead of DUP, but this is mostly due to it requiring
fewer blocks to be
Swâmi Petaramesh posted on Mon, 16 Jun 2014 09:54:01 +0200 as excerpted:
I created a BTRFS filesytem over LVM over LUKS encryption on an SSD
[yes, I know...], and I noticed that the FS got created with metadata in
DUP mode, contrary to what man mkfs.btrfs says for SSDs - it would
be supposed
Le lundi 16 juin 2014, 12:16:33 Duncan a écrit :
Does btrfs automatically add the ssd mount option or do you have to add
it? If you have to add it, that means btrfs isn't detecting the ssd,
First time I mounted the freshly created filesystem, it actually added the
ssd option by itself. Thus
On 06/16/2014 03:26 PM, Tamas Papp wrote:
hi All,
There is a Dell XPS 13 laptop with and SSD.
System:
Ubuntu 14.04 amd64
Kernel is from the daily ppa, like 3.15rcX.
Now, it's running live system:
Linux ubuntu 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC
2014 x86_64 x86_64
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily
Hi Lennart,
On 06/16/2014 12:13 AM, Lennart Poettering wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I mean,
fallocate() isn't necessarily supposed to write anything really, it's
mostly about allocating
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck forever?
-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
Hi all,
in this blog [1] I collected all the results of the tests which I performed in
order to investigate a bit this performance problem between systemd and btrfs.
I had to put these results in a blog, because there are several images. Below a
brief summary.
I took an old machine (a P4
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why this breaks btrfs COW behaviour. I
On 06/16/2014 12:52 PM, Martin wrote:
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck forever?
The following messages are repeatedly output.
And stuck forever.
[ 1147.942181]
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck forever?
The following messages are
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck
On 06/16/2014 03:52 PM, Martin wrote:
On 16/06/14 17:05, Josef Bacik wrote:
On 06/16/2014 03:14 AM, Lennart Poettering wrote:
On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote:
I am not really following though why this trips up btrfs though. I am
not sure I understand why
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on
It's not a mmap problem, it's a small writes with an msync or fsync
after each one problem.
For the case of sequential writes (via write or mmap), padding writes
to page boundaries would help, if the wasted space isn't an issue.
Another approach, again assuming all other writes are appends, would
On Fri, 2014-06-13 at 14:58 -0700, David Rientjes wrote:
On Fri, 13 Jun 2014, Gui Hecheng wrote:
diff --git a/lib/cmdline.c b/lib/cmdline.c
index d4932f7..76a712e 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
* @retptr: (output)
On Tue, 17 Jun 2014, Gui Hecheng wrote:
diff --git a/lib/cmdline.c b/lib/cmdline.c
index d4932f7..76a712e 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
* @retptr: (output) Optional pointer to next char after parse
On 2014/06/17 10:11, Chris Mason wrote:
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup
On 2014/06/17 9:47, Chris Mason wrote:
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when
On 2014/06/17 11:10, Tsutomu Itoh wrote:
On 2014/06/17 9:47, Chris Mason wrote:
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu
On Mon, 2014-06-16 at 18:29 -0700, David Rientjes wrote:
On Tue, 17 Jun 2014, Gui Hecheng wrote:
diff --git a/lib/cmdline.c b/lib/cmdline.c
index d4932f7..76a712e 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
*
On 06/16/2014 11:06 PM, Tsutomu Itoh wrote:
On 2014/06/17 11:10, Tsutomu Itoh wrote:
On 2014/06/17 9:47, Chris Mason wrote:
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris
On 2014/06/17 12:06, Tsutomu Itoh wrote:
On 2014/06/17 11:10, Tsutomu Itoh wrote:
On 2014/06/17 9:47, Chris Mason wrote:
On 06/16/2014 07:57 PM, Tsutomu Itoh wrote:
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason
Hi Filipe,
(2014/06/16 21:14), Filipe David Borba Manana wrote:
The lock_wq wait queue is not used anywhere, therefore just remove it.
On a x86_64 system, this reduced sizeof(struct extent_buffer) from 320
bytes down to 296 bytes, which means a 4Kb page can now be used for
13 extent buffers
38 matches
Mail list logo
