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)
>> >
>
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.
Transact
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
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
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 n
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
> "SI
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 b
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//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 value is, b
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
---
fs/btrfs
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//queue/rotational, if that is 1 it knows
>> that the device isn't a SSD. I believe that LVM passes
On Mon, Jun 16, 2014 at 2:14 PM, 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
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 encr
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 s
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. T
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 x86_6
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 supposed
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 allocati
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.o
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 2.5GH
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 beha
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.94
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 mes
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,
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 sur
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
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 'xfstest
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
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 af
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:
>>>
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 e
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 0
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_optio
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 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,
>>
>>
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 buffer
Hi Marc,
(2014/05/19 22:49), Marc MERLIN wrote:
Ok, that's 2 out of 2.
I was copying pictures from an sdcard (through mmcblk0), and the
filesystem deadlocked.
Unfortunately, when this happens, I copied my pictures (which were still
in RAM) to my 2nd drive which was also btrfs.
From your sysr
38 matches
Mail list logo
