On Wed, 25 Sep 2013 10:11:25 -0400, Josef Bacik wrote:
On Wed, Sep 25, 2013 at 09:47:44PM +0800, Miao Xie wrote:
When doing space balance and subvolume destroy at the same time, we met
the following oops:
kernel BUG at fs/btrfs/relocation.c:2247!
RIP: 0010: [a04cec16]
Hi btrfs guys,
could someone explain to me the differences in mkfs.btrfs:
- between -d raid0 and -d single
- between -m raid1 and -m dup
- between -m raid0 and -m single
My understanding is that raidX should be used in case of multi devices and
single/dup should be used in case of single
On Thu, Sep 26, 2013 at 12:22:49PM +, miaou sami wrote:
Hi btrfs guys,
could someone explain to me the differences in mkfs.btrfs:
- between -d raid0 and -d single
In RAID0, data is striped across all the devices, so the first 64k
of a file will go on device 1, the next 64k will go
On Fri, Sep 20, 2013 at 07:12:47AM +0200, Ingo Molnar wrote:
* Josef Bacik jba...@fusionio.com wrote:
We can starve out the transaction commit with a bunch of caching threads
all running at the same time. This is because we will only drop the
extent_commit_sem if we need_resched(),
* Josef Bacik jba...@fusionio.com wrote:
On Fri, Sep 20, 2013 at 07:12:47AM +0200, Ingo Molnar wrote:
* Josef Bacik jba...@fusionio.com wrote:
We can starve out the transaction commit with a bunch of caching threads
all running at the same time. This is because we will only drop
Btrfs needs a simple way to know if it needs to let go of it's read lock on a
rwsem. Introduce rwsem_is_contended to check to see if there are any waiters on
this rwsem currently. This is just a hueristic, it is meant to be light and not
100% accurate and called by somebody already holding on to
We can starve out the transaction commit with a bunch of caching threads all
running at the same time. This is because we will only drop the
extent_commit_sem if we need_resched(), which isn't likely to happen since we
will be reading a lot from the disk so have already schedule()'ed plenty.
Thank you, it is quite clear now.
I guess that on multi device, raid0 vs single would be a matter of performance
vs ease of low level hardware data recovery.
The wiki
https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices says:
When you have drives with differing sizes and
On Thu, Sep 26, 2013 at 01:40:57PM +, miaou sami wrote:
Thank you, it is quite clear now.
I guess that on multi device, raid0 vs single would be a matter of
performance vs ease of low level hardware data recovery.
The wiki
* Josef Bacik jba...@fusionio.com wrote:
Btrfs needs a simple way to know if it needs to let go of it's read lock on a
rwsem. Introduce rwsem_is_contended to check to see if there are any waiters
on
this rwsem currently. This is just a hueristic, it is meant to be light and
not
100%
On Thu, Sep 26, 2013 at 02:55:38PM +, miaou sami wrote:
OK, that's clear.
Nice space simulator btw :-) you should add a link somewhere in btrfs wiki...
There is one, linked from the first line of the relevant section in
the FAQ.
Hugo.
Thanks
OK, that's clear.
Nice space simulator btw :-) you should add a link somewhere in btrfs wiki...
Thanks
Date: Thu, 26 Sep 2013 14:46:05 +0100
From: h...@carfax.org.uk
To: miaous...@hotmail.com
CC: linux-btrfs@vger.kernel.org
Subject: Re: [raidX vs
On Thu, Sep 19, 2013 at 08:37:07PM -0700, Darrick J. Wong wrote:
When btrfs creates a bioset, we must also allocate the integrity data pool.
Otherwise btrfs will crash when it tries to submit a bio to a checksumming
disk:
BUG: unable to handle kernel NULL pointer dereference at
13 matches
Mail list logo
