Btrfs has supported replace on RAID 5 and 6 since 3.19, but xfstests
hasn't been updated to reflect that. Patches 1 and 2 in this series fix
that.
Additionally, I'm including Wang Yanfeng's test for my patch series
Btrfs: RAID 5/6 missing device scrub+replace, updated to use the
infrastructure
btrfs replace has been supported on RAID 5/6 since Linux 3.19.
Signed-off-by: Omar Sandoval osan...@fb.com
---
tests/btrfs/011 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/btrfs/011 b/tests/btrfs/011
index f4f2fbed68d8..c7d35fa46062 100755
--- a/tests/btrfs/011
Replacing and scrubbing RAID 5/6 is now supported on Btrfs. Enable it in
_btrfs_get_profile_configs while making it more generic to also support
replace missing.
Signed-off-by: Omar Sandoval osan...@fb.com
---
common/rc | 96 ---
1 file
From: Wang Yanfeng wangyf-f...@cn.fujitsu.com
Test of missing device replace in different raid modes. This
test requires SCRATCH_DEV_POOL contain 5 same size devices.
This issue has been fixed by Omar's patch:
Btrfs: RAID 5/6 missing device scrub+replace
Signed-off-by: Wang Yanfeng
On 2015-07-22 10:13, Gregory Farnum wrote:
On Wed, Jul 22, 2015 at 12:16 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2015-07-21 22:01, Qu Wenruo wrote:
Steve Dainard wrote on 2015/07/21 14:07 -0700:
I don't know if this has any bearing on the failure case, but the
filesystem that
On Sun, Jul 19, 2015 at 07:07:40PM -0700, Suman Chakravartula wrote:
We are using 4.1 progs and 4.1 kernel on Rockstor currently and what I
see is that btrfs check says device is not currently mounted. Is 4.1
effected? Do you recommend we update to 4.1.2 anyway?
[root@RockStor ~]# btrfs fi
On Thu, Jul 23, 2015 at 12:29:49PM +0800, Zhaolei wrote:
From: Zhao Lei zhao...@cn.fujitsu.com
Scrub panic in following operation:
mkfs.ext4 /dev/vdh
btrfs-convert /dev/vdh
mount /dev/vdh /mnt/tmp1
btrfs scrub start -B /dev/vdh
(panic)
Reason:
1: In some case, leaf created
On Sat, Jul 11, 2015 at 06:02:29PM -0700, Marc MERLIN wrote:
Are you interested in crash reports for fsck?
If so, see my recent message:
On Mon, Jul 06, 2015 at 02:21:56PM -0700, Marc MERLIN wrote:
myth:~# btrfs check --repair /dev/mapper/crypt_sdd1
enabling repair mode
Checking
Thanks Chris
We will investigate it with highest priority.
Thanks,
Qu
Chris Mason wrote on 2015/07/23 16:21 -0400:
On Wed, Jul 22, 2015 at 05:28:48PM +0800, Qu Wenruo wrote:
Hi Chris,
Is there anything wrong with it?
It has been 2 weeks, and it's still not in your for linus branch.
Is
Chris Mason wrote on 2015/07/23 21:57 -0400:
On Fri, Jul 24, 2015 at 08:29:05AM +0800, Qu Wenruo wrote:
[ deadlock with the 070 patches ]
Thanks Chris
We will investigate it with highest priority.
Thanks,
Qu
Thanks! I'm doing a few more runs to make sure the lockup is new with
these
On Fri, Jul 24, 2015 at 08:29:05AM +0800, Qu Wenruo wrote:
[ deadlock with the 070 patches ]
Thanks Chris
We will investigate it with highest priority.
Thanks,
Qu
Thanks! I'm doing a few more runs to make sure the lockup is new with
these patches.
-chris
--
To unsubscribe from this
On Thu, Jul 23, 2015 at 01:51:50PM -0700, Omar Sandoval wrote:
Replacing and scrubbing RAID 5/6 is now supported on Btrfs. Enable it in
_btrfs_get_profile_configs while making it more generic to also support
replace missing.
Signed-off-by: Omar Sandoval osan...@fb.com
Looks great! Tested
On Thu, Jul 23, 2015 at 01:51:51PM -0700, Omar Sandoval wrote:
From: Wang Yanfeng wangyf-f...@cn.fujitsu.com
Test of missing device replace in different raid modes. This
test requires SCRATCH_DEV_POOL contain 5 same size devices.
This issue has been fixed by Omar's patch:
Btrfs:
james harvey posted on Thu, 23 Jul 2015 19:12:38 + as excerpted:
Up to date Arch. linux kernel 4.1.2-2. Fresh O/S install 12 days ago.
No where near full - 34G used on a 4.6T drive. 32GB memory.
Installed bonnie++ 1.97-1.
$ bonnie++ -d bonnie -m btrfs-disk -f -b
I started
On Thu, Jul 23, 2015 at 01:51:49PM -0700, Omar Sandoval wrote:
btrfs replace has been supported on RAID 5/6 since Linux 3.19.
Signed-off-by: Omar Sandoval osan...@fb.com
Reviewed-by: Eryu Guan eg...@redhat.com
---
tests/btrfs/011 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On 2015-07-23 15:12, james harvey wrote:
Up to date Arch. linux kernel 4.1.2-2. Fresh O/S install 12 days
ago. No where near full - 34G used on a 4.6T drive. 32GB memory.
Installed bonnie++ 1.97-1.
$ bonnie++ -d bonnie -m btrfs-disk -f -b
I started trying to run with a -s 4G option, to
On Wed, Jul 22, 2015 at 05:28:48PM +0800, Qu Wenruo wrote:
Hi Chris,
Is there anything wrong with it?
It has been 2 weeks, and it's still not in your for linus branch.
Is there anything wrong?
I ran this through xfstests again, and got tasks deadlocked during
btrfs/061. Looks like
Up to date Arch. linux kernel 4.1.2-2. Fresh O/S install 12 days
ago. No where near full - 34G used on a 4.6T drive. 32GB memory.
Installed bonnie++ 1.97-1.
$ bonnie++ -d bonnie -m btrfs-disk -f -b
I started trying to run with a -s 4G option, to use 4GB files for
performance measuring. It
Kernel btrfs_map_block() function has a limitation that it can only
map BTRFS_STRIPE_LEN size.
That will cause scrub fails to scrub tree block which crosses strip
boundary, causing BUG_ON().
Normally, it's OK as metadata is always in metadata chunk and
BTRFS_STRIPE_LEN can always be divided by
The problem is originally reported by Chris Murphyli...@colorremedies.com,
and Zhao Lei digs out the root cause:
Metadata extent in mixed block group may cross stripe boundary, causing
scrub can't handle them.
For normal data/metadata separated case, as BTRFS_STRIPE_LEN(64K) can
always be divided
Now find_free_extent() function won't return a metadata extent that
cross stripe boundary.
Reported-by: Chris Murphy li...@colorremedies.com
Reported-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
As convert implement its own alloc extent, avoid such metadata problem
too.
Reported-by: Chris Murphy li...@colorremedies.com
Reported-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
btrfs-convert.c | 15
Although it is fixed to BTRFS_STRIPE_LEN(64K) now, it's still used in a
lot of codes, just output it for user who want to trace the source of
stripe_len in btrfs_map_bio() codes.
Reported-by: Chris Murphy li...@colorremedies.com
Reported-by: Zhao Lei zhao...@cn.fujitsu.com
Signed-off-by: Zhao Lei
From: Filipe Manana fdman...@suse.com
We have another case where after an fsync log replay we get an inode with
a wrong link count (smaller than it should be) and a number of directory
entries greater than its link count. This happens when we add a new link
hard link to our inode A and then we
24 matches
Mail list logo
