Recovering a 4xhdd RAID10 file system with 2 failed disks
Hi all,
Quick and Dirty:
4disk RAID10 with 2 missing devices, mounts as degraded,ro , readonly
scrub ends with no errors
Recovery options:
A/ If you had at least 3 hdds, you could replace/add a device
B/ If you only have 2
When impatient sysadmin is tired of waiting background running btrfs
scrub/replace and send SIGKILL to btrfs process, unlike
SIGINT/SIGTERM which can be caught by user space program and cancel the
scrub work, user space program will continue running until ioctl exits.
To keep it consistent with
Recovering a 4xhdd RAID10 file system with 2 failed disks
Hi all,
Quick and Dirty:
4disk RAID10 with 2 missing devices, mounts as degraded,ro , readonly
scrub ends with no errors
Recovery options:
A/ If you had at least 3 hdds, you could replace/add a device
B/ If you only have 2
Am Montag, 4. August 2014, 14:50:29 schrieb Martin Steigerwald:
Am Freitag, 25. Juli 2014, 11:54:37 schrieb Martin Steigerwald:
Am Donnerstag, 24. Juli 2014, 22:48:05 schrieben Sie:
When failing to allocate space for the whole compressed extent, we'll
fallback to uncompressed IO, but
On Wed, Aug 06, 2014 at 12:21:59PM +0200, Martin Steigerwald wrote:
It basically happened on about the first heavy write I/O occasion after
the BTRFS trees filled the complete device:
I am now balancing the trees down to lower sizes manually with
btrfs balance start -dusage=10 /home
Am Mittwoch, 6. August 2014, 11:29:19 schrieb Hugo Mills:
On Wed, Aug 06, 2014 at 12:21:59PM +0200, Martin Steigerwald wrote:
It basically happened on about the first heavy write I/O occasion after
the BTRFS trees filled the complete device:
I am now balancing the trees down to lower
On Monday 04 August 2014 01:29:49 you wrote:
Hello,
I just had a very frustrating experience with btrfs, which I was only
able to resolve by rolling back to ext4 using the subvol btrfs-convert
created. The same type of situation occurred before when I was using
the ext file system and the
The file hole detection logic during a file fsync wasn't correct,
because it didn't look back (in a previous leaf) for the last file
extent item that can be in a leaf to the left of our leaf and that
has a generation lower than the current transaction id. This made it
assume that a hole exists
On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
I think this should go to stable. Thanks, Liu.
I'm definitely tagging this for stable.
Unfortunately this fix does not seem to fix all lockups.
The traces below are a little different, could you please send the whole
file?
-chris
Just
Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
I think this should go to stable. Thanks, Liu.
I'm definitely tagging this for stable.
Unfortunately this fix does not seem to fix all lockups.
The traces below are a little
I've been testing btrfs send/receive, and to my surprise, the +C (nocow)
attribute I have set on directory for virtual machines images is not preserved.
Is this expected? Having found no information about this issue, I'm asking here.
Info:
$ uname -a
Linux asusntb 3.15.8-1-ARCH #1 SMP PREEMPT Fri
On Fri, May 30, 2014 at 8:16 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
btrfs_punch_hole() will truncate unaligned pages or punch hole on a
already existed hole.
This will cause unneeded zero page or holes splitting the original huge
hole.
This patch will skip already existed holes before
Hi,
I wonder how I should handle missing space on the backup device when doing
incremental backup with btrfs send?
I mean for the initial bootstrap it is easy, I simply compare the free space
of the target device with the size of home (we are talking about incremental
backups of home), but how
Hi Filipe,
Thanks for the test result, I'll investigate it soon.
Also I'll fix the code style problem too.
Thanks,
Qu
Original Message
Subject: Re: [PATCH] btrfs: Avoid trucating page or punching hole in a
already existed hole.
From: Filipe David Manana fdman...@gmail.com
On 08/06/2014 11:18 AM, Chris Mason wrote:
On 08/06/2014 10:43 AM, Martin Steigerwald wrote:
Am Mittwoch, 6. August 2014, 09:35:51 schrieb Chris Mason:
On 08/06/2014 06:21 AM, Martin Steigerwald wrote:
I think this should go to stable. Thanks, Liu.
I'm definitely tagging this for stable.
The -d, -i, -n options make no sense to rollback.
Check the improper usages such as:
# btrfs-convert -r -d dev
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
btrfs-convert.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/btrfs-convert.c b/btrfs-convert.c
The @force parameter for function @do_rollback is never checked
or used, remove it.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
btrfs-convert.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-convert.c b/btrfs-convert.c
index 2ea6a09..21bbc70 100644
---
The close_ctree always returns 0 and the stuff that depends on
its return value is of no sense.
Just make close_ctree return void.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
btrfs-convert.c| 14 +++---
btrfs-debug-tree.c | 3 ++-
btrfs-image.c | 4 ++--
disk-io.c
It seems that the patch is rejected in patchwork,
Could any one tell me the reason?
Thanks,
Qu
Original Message
Subject: [PATCH] btrfs: Don't continue mounting when superblock csum
mismatches even generation is less than 10.
From: Qu Wenruo quwen...@cn.fujitsu.com
To:
19 matches
Mail list logo
