Re: [PATCH 05/14] Btrfs: warn_on for unaccounted spaces

Hi Josef, Would you please move this patch to the first of the patchset? It's making bisect quite hard, as it will always stop at this patch, hard to check if it's a regression or existing bug. Thanks, Qu At 03/26/2016 01:25 AM, Josef Bacik wrote: These were hidden behind enospc_debug,

Re: [PATCH 1/4] fstests: btrfs/048: extend _filter_btrfs_prop_error to handle additional errors

On Fri, Jun 24, 2016 at 11:08:31AM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > btrfsprogs v4.5.3 changed the formatting of some error messages. This > patch extends the filter for btrfs prop to handle those. > > Signed-off-by: Jeff Mahoney > --- >

Re: Strange behavior when replacing device on BTRFS RAID 5 array.

On Sun, Jun 26, 2016 at 8:57 PM, Nick Austin wrote: > sudo btrfs fi show /mnt/newdata > Label: '/var/data' uuid: e4a2eb77-956e-447a-875e-4f6595a5d3ec > Total devices 4 FS bytes used 8.07TiB > devid1 size 5.46TiB used 2.70TiB path /dev/sdg > devid

Strange behavior when replacing device on BTRFS RAID 5 array.

I have a 4 device BTRFS RAID 5 filesystem. One of the device members of this file system (sdr) had badblocks, so I decided to replace it. (I don't have a copy of fi show from before the replace. :-/ ) I ran this command: sudo btrfs replace start 4 /dev/sdw /mnt/newdata I had to shrink /dev/sdr

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On Sun, 2016-06-26 at 15:33 -0700, ronnie sahlberg wrote: > 1, a much more strongly worded warning in the wiki. Make sure there > are no misunderstandings > that they really should not use raid56 right now for new filesystems. I doubt most end users can be assumed to read the wiki... > 2,

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On 2016-06-27 08:38, Hugo Mills wrote: On Sun, Jun 26, 2016 at 03:33:08PM -0700, ronnie sahlberg wrote: On Sat, Jun 25, 2016 at 7:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Could this explain why people have been reporting so many raid56 mode > cases of btrfs replacing a first drive

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On 2016-06-27 08:33, ronnie sahlberg wrote: On Sat, Jun 25, 2016 at 7:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: Chris Murphy posted on Sat, 25 Jun 2016 11:25:05 -0600 as excerpted: Wow. So it sees the data strip corruption, uses good parity on disk to fix it, writes the fix to disk,

Re: [PATCH v11 00/13] Btrfs dedupe framework

At 06/25/2016 01:45 PM, Chandan Rajendra wrote: On Saturday, June 25, 2016 09:22:44 AM Qu Wenruo wrote: On 06/24/2016 05:29 PM, Chandan Rajendra wrote: On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote: Hi Chandan, David, When I'm trying to rebase dedupe patchset on top of Chadan's sub

Re: [PATCH 04/31] btrfs: tests, move initialization into tests/

On 6/26/16 10:17 PM, Qu Wenruo wrote: > > > At 06/25/2016 06:14 AM, je...@suse.com wrote: >> From: Jeff Mahoney >> >> We have all these stubs that only exist because they're called from >> btrfs_run_sanity_tests, which is a static inside super.c. Let's just >> move it all into

Re: [PATCH 03/31] btrfs: btrfs_test_opt and friends should take a btrfs_fs_info

At 06/27/2016 10:21 AM, Jeff Mahoney wrote: On 6/26/16 10:14 PM, Qu Wenruo wrote: At 06/25/2016 06:14 AM, je...@suse.com wrote: From: Jeff Mahoney btrfs_test_opt and friends only use the root pointer to access the fs_info. Let's pass the fs_info directly in preparation

Re: [PATCH 03/31] btrfs: btrfs_test_opt and friends should take a btrfs_fs_info

On 6/26/16 10:14 PM, Qu Wenruo wrote: > > > At 06/25/2016 06:14 AM, je...@suse.com wrote: >> From: Jeff Mahoney >> >> btrfs_test_opt and friends only use the root pointer to access >> the fs_info. Let's pass the fs_info directly in preparation to >> eliminate similar patterns

Re: [PATCH 04/31] btrfs: tests, move initialization into tests/

At 06/25/2016 06:14 AM, je...@suse.com wrote: From: Jeff Mahoney We have all these stubs that only exist because they're called from btrfs_run_sanity_tests, which is a static inside super.c. Let's just move it all into tests/btrfs-tests.c and only have one stub.

Re: [PATCH 03/31] btrfs: btrfs_test_opt and friends should take a btrfs_fs_info

At 06/25/2016 06:14 AM, je...@suse.com wrote: From: Jeff Mahoney btrfs_test_opt and friends only use the root pointer to access the fs_info. Let's pass the fs_info directly in preparation to eliminate similar patterns all over btrfs. Signed-off-by: Jeff Mahoney

Re: [PATCH 02/31] btrfs: prefix fsid to all trace events

At 06/25/2016 06:14 AM, je...@suse.com wrote: From: Jeff Mahoney When using trace events to debug a problem, it's impossible to determine which file system generated a particular event. This patch adds a macro to prefix standard information to the head of a trace event. The

Re: [PATCH 00/31] btrfs: simplify use of struct btrfs_root pointers

At 06/25/2016 06:14 AM, je...@suse.com wrote: From: Jeff Mahoney One of the common complaints I've heard from new and experienced developers alike about the btrfs code is the ubiquity of struct btrfs_root. There is one for every tree on disk and it's not always obvious which

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On Sun, Jun 26, 2016 at 03:33:08PM -0700, ronnie sahlberg wrote: > On Sat, Jun 25, 2016 at 7:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Could this explain why people have been reporting so many raid56 mode > > cases of btrfs replacing a first drive appearing to succeed just fine, > > but then

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On Sat, Jun 25, 2016 at 7:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Chris Murphy posted on Sat, 25 Jun 2016 11:25:05 -0600 as excerpted: > >> Wow. So it sees the data strip corruption, uses good parity on disk to >> fix it, writes the fix to disk, recomputes parity for some reason but >> does

Re: Bad hard drive - checksum verify failure forces readonly mount

On Sun, Jun 26, 2016 at 7:05 AM, Vasco Almeida wrote: > A Sáb, 25-06-2016 às 14:54 -0600, Chris Murphy escreveu: >> On Sat, Jun 25, 2016 at 2:10 PM, Vasco Almeida > > wrote: >> > Citando Chris Murphy : >> > > 3. btrfs-image

Re: Adventures in btrfs raid5 disk recovery

On Sun, Jun 26, 2016 at 1:54 AM, Andrei Borzenkov wrote: > 26.06.2016 00:52, Chris Murphy пишет: >> Interestingly enough, so far I'm finding with full stripe writes, i.e. >> 3x raid5, exactly 128KiB data writes, devid 3 is always parity. This >> is raid4. > > That's not what

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On Sun, Jun 26, 2016 at 3:20 AM, Goffredo Baroncelli wrote: > On 2016-06-26 00:33, Chris Murphy wrote: >> On Sat, Jun 25, 2016 at 12:42 PM, Goffredo Baroncelli >> wrote: >>> On 2016-06-25 19:58, Chris Murphy wrote: >>> [...] > Wow. So it sees the data

Re: Adventures in btrfs raid5 disk recovery

Andrei Borzenkov posted on Sun, 26 Jun 2016 10:54:16 +0300 as excerpted: > P.S. usage of "stripe" to mean "stripe element" actually adds to > confusion when reading code :) ... and posts (including patches, which I guess are code as well, just not applied yet). I've been noticing that in the

Re: [PATCH 00/31] btrfs: simplify use of struct btrfs_root pointers

On 6/24/16 6:14 PM, je...@suse.com wrote: > From: Jeff Mahoney > > One of the common complaints I've heard from new and experienced > developers alike about the btrfs code is the ubiquity of > struct btrfs_root. There is one for every tree on disk and it's not > always obvious

Re: Bad hard drive - checksum verify failure forces readonly mount

A Sáb, 25-06-2016 às 14:54 -0600, Chris Murphy escreveu: > On Sat, Jun 25, 2016 at 2:10 PM, Vasco Almeida > wrote: > > Citando Chris Murphy : > > > 3. btrfs-image so that devs can see what's causing the problem > > > that > > > the current code

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5

On 2016-06-26 00:33, Chris Murphy wrote: > On Sat, Jun 25, 2016 at 12:42 PM, Goffredo Baroncelli > wrote: >> On 2016-06-25 19:58, Chris Murphy wrote: >> [...] Wow. So it sees the data strip corruption, uses good parity on disk to fix it, writes the fix to disk,

Re: Adventures in btrfs raid5 disk recovery

26.06.2016 00:52, Chris Murphy пишет: > Interestingly enough, so far I'm finding with full stripe writes, i.e. > 3x raid5, exactly 128KiB data writes, devid 3 is always parity. This > is raid4. That's not what code suggests and what I see in practice - parity seems to be distributed across all