On 02/12/11 15:14, krz...@gmail.com wrote:
> I've upgraded to newest kernel 3.1.2 but problem is not fixed.
As btrfs is an experimental filesystem I don't believe that fixes are
backported to those stable releases, they only go into Linus's tree for
his next release (3.2 in this case). So I'm a
Hello Josef,
Will do, thanks! As soon as I have results I will let you know.
I did already a rerun (without the bigger buffer size), but
unfortunately I couldn't get the trace (like Christian). If I tried to
cat from the trace it hung.
Stefan
On 12/01/2011 04:14 PM, Josef Bacik wrote:
On S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 07:04 PM, Jeff Mahoney wrote:
> On 11/28/2011 06:53 PM, Andi Kleen wrote:
>> Jeff Mahoney writes:
>
>>> The extent_state structure is used at the core of the extent
>>> i/o code for managing flags, locking, etc. It requires
>>> allocati
On Thu, Dec 01, 2011 at 09:20:53AM +0100, Tobias wrote:
> Hi Chris
>
> Am 30.11.2011 15:10, schrieb Chris Mason:
> >We see a bunch of procs stuck waiting to start a transaction, but we
> >don't see why they are waiting. Could you please capture a sysrq-t
> >during this? That will show us all the
Hallo, Phillip,
Du meintest am 01.12.11:
>>> balance != resize
[...]
>> That has nothing to do with "resize".
> Right, so why are you talking about balance when this thread is about
> resize?
Ooops - sorry!
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe li
On 12/1/2011 1:46 AM, Helmut Hullen wrote:
balance != resize
I know.
p.e.
Start with 1 disk with 2 GB and 1 disk with 4 GByte
Fill it with 2 Gbyte data, each disk gets 1 GByte.
Add a disk with 10 GByte, run "balance": each disk gets about 700 MByte.
That has nothing to do with "resize".
Ri
Hi everyone,
The for-linus branch of the btrfs tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Has our current set of fixes. This is fairly small, Alexandre Oliva has
been chasing problems in our block allocator and kicked out important
fixes.
Jan Schmidt fi
On Sat, Nov 26, 2011 at 03:14:37PM +0100, Stefan Kleijkers wrote:
> Hello Josef,
>
> I've new results, is this the trace you are looking for?
>
> Trace of OSD0: http://pastebin.com/gddLBXE4
> Dmesg of OSD0: http://pastebin.com/Uebzgkjv
>
> OSD1 crashed a while later with the same messages.
>
W
Commit 4a54c8c16 introduced raid-repair, killing the individual
readpage_io_failed_hook entries from inode.c and disk-io.c. Commit
4bb31e92 introduced new readahead code, adding a readpage_io_failed_hook to
disk-io.c.
The raid-repair commit had logic to disable raid-repair, if
readpage_io_failed_h
2011/12/1 Alexandre Oliva :
> On Nov 29, 2011, Christian Brunner wrote:
>
>> When I'm doing havy reading in our ceph cluster. The load and wait-io
>> on the patched servers is higher than on the unpatched ones.
>
> That's unexpected.
>
>> This seems to be coming from "btrfs-endio-1". A kernel thre
In the case where the orphan_del fails, and cannot return
error to the caller, the filesystem turns to readonly instead
of BUG_ON().
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/inode.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.
The filesystem turns to readonly instead of BUG_ON() when
free_log_tree fails.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/tree-log.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index f4d81c0..44bcfba 100644
--- a/fs/btrfs/
On 26.11.2011 05:14, Phillip Susi wrote:
> On 07/10/2011 04:21 AM, Arne Jansen wrote:
>> Now that I've got a working prototype of subvolume quota, I'd like
>> to get some feedback on the on-disk structure and the commands I
>> intend to use.
>
> I think I've noticed a bug so far, and have one comm
On 17.11.2011 15:06, Thomas Schmidt wrote:
> Original-Nachricht
>> Datum: Thu, 17 Nov 2011 13:59:26 +0100
>> Von: Arne Jansen
>> An: Thomas Schmidt
>> CC: linux-btrfs@vger.kernel.org
>> Betreff: Re: [RFC] improve space utilization on off-sized raid devices
>
>
> Consider a 4 d
14 matches
Mail list logo