On Thu, Jul 23, 2015 at 01:51:51PM -0700, Omar Sandoval wrote:
> From: Wang Yanfeng
>
> 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 devic
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
Looks great! Tested with default
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
Reviewed-by: Eryu Guan
> ---
> tests/btrfs/011 | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/b
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 pa
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
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 start
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 ther
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 a
btrfs replace has been supported on RAID 5/6 since Linux 3.19.
Signed-off-by: Omar Sandoval
---
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
+++ b/tests/btrf
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
---
common/rc | 96 ---
1 file changed, 49 in
From: Wang Yanfeng
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
Signed-off-by: Omar Sandoval
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 lik
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
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. I
On Thu, Jul 23, 2015 at 12:29:49PM +0800, Zhaolei wrote:
> From: Zhao Lei
>
> 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 by btrfs-co
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
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
>
On 2015-07-22 10:13, Gregory Farnum wrote:
On Wed, Jul 22, 2015 at 12:16 PM, Austin S Hemmelgarn
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 I sent an image of w
From: Filipe Manana
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 fsync some other ino
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
Reported-by: Zhao Lei
Signed-off-by: Zhao Lei
Signed-off-by: Qu Wenruo
---
print-tree.c
Now find_free_extent() function won't return a metadata extent that
cross stripe boundary.
Reported-by: Chris Murphy
Reported-by: Zhao Lei
Signed-off-by: Zhao Lei
Signed-off-by: Qu Wenruo
---
extent-tree.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/extent-tree.c b/extent-tree.c
As convert implement its own alloc extent, avoid such metadata problem
too.
Reported-by: Chris Murphy
Reported-by: Zhao Lei
Signed-off-by: Zhao Lei
Signed-off-by: Qu Wenruo
---
btrfs-convert.c | 15 ---
ctree.h | 2 +-
extent-tree.c | 2 +-
3 files changed, 14 insertio
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 nod
The problem is originally reported by Chris Murphy,
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 by nodesize (4~64K, pow
24 matches
Mail list logo
