>> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> >> ow...@vger.kernel.org] On Behalf Of Chris Murphy
>> >> Sent: Thursday, 1 September 2016 7:59 AM
>> >> To: Btrfs BTRFS
>> >> Subject: Re: btrfs-progs 4.7, check reports many "incorre
OK I filed a bug:
progs 4.7.x, numerous incorrect backrefs are not fixed with --repair
https://bugzilla.kernel.org/show_bug.cgi?id=155791
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
...@vger.kernel.org] On Behalf Of Chris Murphy
> >> Sent: Thursday, 1 September 2016 7:59 AM
> >> To: Btrfs BTRFS
> >> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local
> >> backref count" messages
> >>
> >> This is
OK so I have a 2nd volume, which is only ever used to 'btrfs receive'
from the 1st volume. The 2nd volume is never persistently mounted. But
it too has bunches of these incorrect backref messages, where
btrfs-progs 4.6.1 comes up clean. A 3rd volume, is only ever used to
receive rsync from the 1st
On Thu, Sep 1, 2016 at 11:59 AM, Chris Murphy wrote:
> OK so I have a 2nd volume, which is only ever used to 'btrfs receive'
> from the 1st volume. The 2nd volume is never persistently mounted. But
> it too has bunches of these incorrect backref messages, where
> btrfs-progs 4.6.1 comes up clean.
gt;> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local backref
>> count" messages
>>
>> This is still happening with btrfs-progs 4.7.1 and there is zero information
>> in
>> the long result what to do about the problem, and whether it
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Chris Murphy
> Sent: Thursday, 1 September 2016 7:59 AM
> To: Btrfs BTRFS
> Subject: Re: btrfs-progs 4.7, check reports many "incorrect local ba
This is still happening with btrfs-progs 4.7.1 and there is zero
information in the long result what to do about the problem, and
whether it's sane to try have --repair fix it, let alone what the
original cause of the problem was.
--
Chris Murphy
--
To unsubscribe from this list: send the line
On Wed, Aug 24, 2016 at 11:59 AM, Chris Murphy wrote:
> Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree
>
> [chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1
> btrfs-progs v4.7
> checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
> check
[chris@f24s ~]$ btrfs --version
btrfs-progs v4.5.3
[chris@f24s ~]$ sudo btrfs check /dev/mapper/brick1
Checking filesystem on /dev/mapper/brick1
UUID: 30f4724a-9a9f-4a5d-a37d-3e53876bf2e1
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 4233021239
Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree
[chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1
btrfs-progs v4.7
checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
checksum verify failed on 16913485824 found FEAA7A13 wanted 2000
by
[chris@f24s ~]$ sudo btrfs dev stats /brick1
[/dev/mapper/brick1].write_io_errs 0
[/dev/mapper/brick1].read_io_errs0
[/dev/mapper/brick1].flush_io_errs 0
[/dev/mapper/brick1].corruption_errs 0
[/dev/mapper/brick1].generation_errs 0
[chris@f24s ~]$ sudo btrfs scrub status /brick1
scrub stat
See attached for 'btrfs check' output.
The last check was about two weeks ago when btrfs-progs 4.7 was
released, and it came up clean. The file system has only been written
to since then with a 4.7.0 kernel, and 4.7.2 kernel for the past ~36
hours.
The workload in those two weeks has only been cu
13 matches
Mail list logo