On Mon, Feb 16, 2015 at 12:19:58PM +0800, Liu Bo wrote:
On Mon, Feb 16, 2015 at 11:33:37AM +1100, Dave Chinner wrote:
On Fri, Feb 13, 2015 at 12:47:54PM +, Filipe Manana wrote:
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data,
Original Message
Subject: Re: btrfs check --init-csum-tree removes csums again
From: Karl-Philipp Richter rich...@richtercloud.de
To: Tim DeNike t...@denike.us, Btrfs BTRFS linux-btrfs@vger.kernel.org
Date: 2015年02月17日 12:18
Hi,
Now I could rebuild the csum tree with `--repair
re: Karl-Philipp's attached log, I had pretty much identical messages
as well, just no crash like he did.
So now I'm suspicious this corruption was instigated by btrfs-progs
3.12's --init-csum-tree on a new btrfs volume. After updating to
btrfs-progs 3.18.2, it showed many similar complaints as
Duncan 1i5t5.dun...@cox.net schrieb:
It's probably just a flaw that
btrfs device composition comes up later and the kernel tries to early to
mount root. rootwait probably won't help here, too. But rootdelay
may help that case tho I myself don't have the ambitions to experiment
with it. My
Hi,
Now I could rebuild the csum tree with `--repair --init-csum-tree` with
3.18.2 on Linux 3.19, see the attached output for the things which were
fixed and probably caused the problem.
Thanks for your suggestions!
Best regards,
Kalle
Am 16.02.2015 um 12:19 schrieb Karl-Philipp Richter:
Hi,
On Mon, Feb 16, 2015 at 09:02:05AM +0800, Qu Wenruo wrote:
Just like label change, use sb_want_write() to do a correct protection.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
Reviewed-by: David Sterba dste...@suse.cz
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
On Sun, 15 Feb 2015 21:01:07 +, Holger Hoffstätte wrote:
Here's a new one (with kernel 3.18.7++):
$btrfs --version
Btrfs v3.18.2 (also tried 3.19-rc2)
$mount /dev/sdf1 /mnt/usb
$btrfs filesystem df /mnt/usb
Data, single: total=8.00MiB, used=256.00KiB
System, single:
On Mon, Feb 16, 2015 at 10:24 AM, Filipe David Manana
fdman...@gmail.com wrote:
On Mon, Feb 16, 2015 at 10:07 AM, Liu Bo bo.li@oracle.com wrote:
On Sun, Feb 15, 2015 at 10:29:43PM +, Filipe David Manana wrote:
On Sun, Feb 15, 2015 at 4:39 AM, Liu Bo bo.li@oracle.com wrote:
On Fri,
On Mon, Feb 16, 2015 at 11:32:56AM +0900, Tomasz Chmielewski wrote:
I had a failed drive in RAID-1, so it was replaced with a good one,
followed by:
btrfs device add /dev/sdb4 /home
btrfs device delete missing /home
4 days later, it got to a state when there is no IO anymore
(according
On 2015-02-16 19:40, Liu Bo wrote:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
6269 root 20 0 000 R 92.5 0.0 2769:33
btrfs-transacti
22247 root 20 0 000 R 92.5 0.0 42:38.65
kworker/u16:16
Can you cat /proc/22247/stack and
On Mon, Feb 16, 2015 at 10:24:02AM +, Filipe David Manana wrote:
On Mon, Feb 16, 2015 at 10:07 AM, Liu Bo bo.li@oracle.com wrote:
On Sun, Feb 15, 2015 at 10:29:43PM +, Filipe David Manana wrote:
On Sun, Feb 15, 2015 at 4:39 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Feb 13,
Original Message
Subject: Re: btrfs check --init-csum-tree removes csums again
From: Chris Murphy li...@colorremedies.com
To: Karl-Philipp Richter rich...@richtercloud.de
Date: 2015年02月16日 13:59
On Sun, Feb 15, 2015 at 1:50 AM, Karl-Philipp Richter
rich...@richtercloud.de
On Sat, Feb 14, 2015 at 09:18:39PM +0800, Zhaolei wrote:
From: Zhao Lei zhao...@cn.fujitsu.com
Old code bypass commit transaction when we don't have enough
pinned space, but another case is there exist freed bgs in current
transction, it have possibility to make alloc_chunk success.
This
alloc_chunk is used to avoid alloc_chunk for free space cache inode, but since
it's safe now to do that, let's just remove it.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/extent-tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
On Mon, Feb 16, 2015 at 12:33 AM, Dave Chinner da...@fromorbit.com wrote:
On Fri, Feb 13, 2015 at 12:47:54PM +, Filipe Manana wrote:
This test is motivated by an fsync issue discovered in btrfs.
The issue was that we could lose file data, that was previously fsync'ed
successfully, if we
On Mon, Feb 16, 2015 at 9:32 AM, Liu Bo bo.li@oracle.com wrote:
alloc_chunk is used to avoid alloc_chunk for free space cache inode, but
since
it's safe now to do that, let's just remove it.
Already submitted 2 times before:
https://patchwork.kernel.org/patch/5828631/
On Sun, Feb 15, 2015 at 10:29:43PM +, Filipe David Manana wrote:
On Sun, Feb 15, 2015 at 4:39 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Feb 13, 2015 at 04:56:14PM +, Filipe Manana wrote:
If we are recording in the tree log that an inode has new names (new hard
links were
I just ran through with vanilla 3.19 kernel and btrfs-progs 3.18.2
with the same result. Nothing in kernel log at all. Output of btrfs
check below.
[root@938el btrfs-progs]# ./btrfs check --repair --init-csum-tree /dev/sda
enabling repair mode
Creating a new CRC tree
Checking filesystem on
On Mon, Feb 16, 2015 at 9:45 AM, Filipe David Manana fdman...@gmail.com wrote:
On Mon, Feb 16, 2015 at 12:33 AM, Dave Chinner da...@fromorbit.com wrote:
On Fri, Feb 13, 2015 at 12:47:54PM +, Filipe Manana wrote:
This test is motivated by an fsync issue discovered in btrfs.
The issue was
On Mon, Feb 16, 2015 at 10:07 AM, Liu Bo bo.li@oracle.com wrote:
On Sun, Feb 15, 2015 at 10:29:43PM +, Filipe David Manana wrote:
On Sun, Feb 15, 2015 at 4:39 AM, Liu Bo bo.li@oracle.com wrote:
On Fri, Feb 13, 2015 at 04:56:14PM +, Filipe Manana wrote:
If we are recording in
On Mon, Feb 16, 2015 at 11:11 AM, Liu Bo bo.li@oracle.com wrote:
On Mon, Feb 16, 2015 at 10:24:02AM +, Filipe David Manana wrote:
On Mon, Feb 16, 2015 at 10:07 AM, Liu Bo bo.li@oracle.com wrote:
On Sun, Feb 15, 2015 at 10:29:43PM +, Filipe David Manana wrote:
On Sun, Feb 15,
Hi,
I get the same output except some differences in address offsets:
$ sudo btrfs check --init-csum-tree /dev/disk/by-uuid/bd6298ea-
0748-45fe-87c8-eace6793ca89
Creating a new CRC tree
Checking filesystem on
/dev/disk/by-uuid/bd6298ea-0748-45fe-87c8-eace6793ca89
UUID:
From: Zhao Lei zhao...@cn.fujitsu.com
It is another reason of NO_SPACE bug.
When we found enough free space in loop and saved them to
max_hole_start/size before, and tail space contains pending extent,
origional innocent max_hole_start/size data are reset in retry.
As a result,
23 matches
Mail list logo
