On Fri, 29 Aug 2014 14:31:48 -0400, Chris Mason wrote:
On 07/29/2014 05:24 AM, Miao Xie wrote:
This patch implement data repair function when direct read fails.
The detail of the implementation is:
- When we find the data is not right, we try to read the data from the other
mirror.
-
--
Lieber Freund,
Wie geht es Ihnen heute? Ich hoffe, fein, ich bin Dr. Martin Dustin aus
Harlesden , North West London, hier in England. Ich arbeite für NatWest
Bank London (National Westminster Bank Plc. ) . Ich schreibe Ihnen aus
meinem Büro , die von einer großen immensen Nutzen für
Guy,
Am Donnerstag 28 August 2014, 10:28:02 schrieb Gui Hecheng:
On Mon, 2014-08-25 at 05:08 +, Zooko Wilcox-OHearn wrote:
Aha. When it is run under valgrind it consistently stops (killing
valgrind, in fact!) in the same way on every run.
Here's the tail of stdout and stderr when it
Am Montag 01 September 2014, 10:47:26 schrieb Marc Dietrich:
Guy,
Am Donnerstag 28 August 2014, 10:28:02 schrieb Gui Hecheng:
And for the last one and the crucial one...
==5569== Invalid read of size 4
==5569==at 0x41E394: decompress (cmds-restore.c:93)
==5569==by 0x41F291:
Hi.
I'm not sure if this is related to the hung task problem that I've
been seeing in this ml for a while. But I've been having this
seemingly related problem with 3.15, 3.16 and now 3.17-rc3 (which, if
I'm not mistaken, should have a fix for the hung task problem). So
here it is: I have a usb
On Fri, Aug 29, 2014 at 11:12:28PM +0200, Toralf Förster wrote:
At as 32 bit KVM I run these 2 commands:
tfoerste@n22kvm ~ $ mkdir /mnt/ramdisk/btrfs; truncate -s 97M
/mnt/ramdisk/btrfs.fs; /sbin/mkfs.btrfs /mnt/ramdisk/btrfs.fs; sudo su -c
mount -o loop,compress=lzo /mnt/ramdisk/btrfs.fs
I'm more than happy to try out patches and even focus my own brain on
diagnosing it, if I can. I'm hoping to regain access to some of my
files on my btrfs partition, and also I would enjoy helping get this
improved. :-)
So if you want me to try an experiment, just email me. Unfortunately I
can't
On 09/01/2014 09:33 AM, john terragon wrote:
Hi.
I'm not sure if this is related to the hung task problem that I've
been seeing in this ml for a while. But I've been having this
seemingly related problem with 3.15, 3.16 and now 3.17-rc3 (which, if
I'm not mistaken, should have a fix for
On Sat, Aug 30, 2014 at 11:26:52AM -1000, Jean-Denis Girard wrote:
So I commented out the break on line 238 of btrfs-find-root so that it
Thanks for that report.
Can a developer review this and see if it should be made an option or
removed entirely?
Marc
continues even if it thinks it went
I was trying it again and it seems to have completed, albeit very
slowly (even for an usb flash drive). Was the 3.14 series the last
immune one from this problem? Should I try the latest 3.14.x?
Thanks
John
On Mon, Sep 1, 2014 at 6:02 PM, Chris Mason c...@fb.com wrote:
On 09/01/2014 09:33 AM,
On 1/9/2014 7:27 μμ, Marc MERLIN wrote:
On Sat, Aug 30, 2014 at 11:26:52AM -1000, Jean-Denis Girard wrote:
So I commented out the break on line 238 of btrfs-find-root so that it
Thanks for that report.
Can a developer review this and see if it should be made an option or
removed entirely?
I
On 09/01/2014 03:41 PM, Liu Bo wrote:
I believe that this warning of btrfs_evict_inode also comes from a result of
lseek, and Chris said that he's prepared a fix for that, so it's queued in the
next version.
thanks,
-liubo
Ah thx, it seems that fix does not made it in -rc3, so -rc4 would
On Tue, Aug 26, 2014 at 07:39:08PM -0400, Nikolai Grigoriev wrote:
Hi,
This is not exactly a problem - I am trying to understand why BTRFS
demonstrates significantly higher throughput in my environment.
I am observing something that I cannot explain. I am trying to come up
with a good
On Tue, Sep 02, 2014 at 10:08:22AM +1000, Dave Chinner wrote:
Pretty obvious difference: avgrq-sz. btrfs is doing 512k IOs, ext4
and XFS are doing is doing 128k IOs because that's the default block
device readahead size. 'blockdev --setra 1024 /dev/sdd' before
mounting the filesystem will
I had a multi-drive raid6 setup and failed and removed 2 drives. I tried
to start a scrub and rebalance to recalculate the parity and something
happened where I could not write to the filesystem. Any programs that
tried to interact with the filesystem would stall forever and bring the
server load
Original Message
Subject: Re: find_mount_root() issue
From: Duncan 1i5t5.dun...@cox.net
To: linux-btrfs@vger.kernel.org
Date: 2014年08月31日 17:41
Remco Hosman - Yerf IT.nl posted on Sun, 31 Aug 2014 09:37:38 +0200 as
excerpted:
issue:
on my system i have 2 entries for /, one
Original Message
Subject: Re: find_mount_root() issue
From: Qu Wenruo quwen...@cn.fujitsu.com
To: Duncan 1i5t5.dun...@cox.net, re...@yerf-it.nl
Date: 2014年09月02日 09:33
Original Message
Subject: Re: find_mount_root() issue
From: Duncan 1i5t5.dun...@cox.net
Le 01/09/2014 07:00, Konstantinos Skarlatos a écrit :
Until then, can we make this into a concise set of instructions so we
can post it on the wiki?
I would be happy to contribute to the wiki, but I'm not sure where to
add this: a new paragraph in the Problem FAQ or a new page?
Thanks,
On Mon, Sep 01, 2014 at 06:08:28PM -1000, Jean-Denis Girard wrote:
Le 01/09/2014 07:00, Konstantinos Skarlatos a écrit :
Until then, can we make this into a concise set of instructions so we
can post it on the wiki?
I would be happy to contribute to the wiki, but I'm not sure where to
add
john terragon posted on Mon, 01 Sep 2014 18:36:49 +0200 as excerpted:
I was trying it again and it seems to have completed, albeit very slowly
(even for an usb flash drive). Was the 3.14 series the last immune one
from this problem? Should I try the latest 3.14.x?
The 3.14 series was before
20 matches
Mail list logo
