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 dis
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, recomputes parity for some
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 isn't handling well enough.
> >
> >
> > btrfs-image
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 which root is need
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 "s
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 strip corruption, uses good parity on dis
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 code suggests and what
On Sun, Jun 26, 2016 at 01:30:03PM -0600, Chris Murphy wrote:
> 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 alway
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 so that devs can see what's causing the problem
>> > > that
>> > > the cur
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 i
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
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 root is needed i
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 extent_state all
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
---
fs/btrfs/ctree.h
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.
Signed-off-by: Jeff Mahoney
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 all over btrfs.
>>
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 to
eliminate simil
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 tests/btrfs-tests
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
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, recompu
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 appearing
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, Instead
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
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
> devid2 size 5.46TiB used
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
> ---
> common/filter.btrfs | 10 +++---
27.06.2016 06:50, Christoph Anton Mitterer пишет:
>
> What should IMHO be done as well is giving a big fat warning in the
> manpages/etc. that when nodatacow is used RAID recovery cannot produce
> valid data (at least as long as there isn't checksumming implemented
> for nodatacow).
The problem i
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, whic
A Dom, 26-06-2016 às 13:54 -0600, Chris Murphy escreveu:
> On Sun, Jun 26, 2016 at 7:05 AM, Vasco Almeida > wrote:
> > I have tried "btrfs check --repair /device" but that seems do not
> > do
> > any good.
> > http://paste.fedoraproject.org/384960/66945936/
>
> It did fix things, in particular wi
28 matches
Mail list logo