Well it looks like things have stabilizedfor the
moment at least.
$ btrfs scrub start --offline --progress /dev/disk/by-id/XX3
Doing offline scrub [o] [681/681]
Scrub result:
Tree bytes scrubbed: 5234425856
Tree extents scrubbed: 638968
Data bytes scrubbed: 4353724284928
Data extents
s, but not always, trigger as well, but the most frequent symptom
> really was checksum verification failures untarring tbz2s.
I'll have to try and recreate this using my EXT4 system disk.
Zak Kohler posted on Sun, Oct 29, 2017 at 9:57 PM as excerpted:
> I'm running '$ sudo btrfs scrub st
On Sun, Oct 29, 2017 at 3:05 PM, Chris Murphy <li...@colorremedies.com> wrote:
> On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler <y...@y2kbugger.com> wrote:
>
>> I will gladly repeat this process, but I am very concerned why this
>> corruption happened in the first pla
ch will be hard to recovery.
>
> I suggest running offline scrub on all devices. Then online scrub
>
> and finally track those corrupted files with the help of extent info.
>
>
> Cheers,
> Lakshmipathi.G
> http://www.giis.co.in http://www.webminal.org
>
the device that is currently being scanned is sdh.
On Tue, Oct 24, 2017 at 2:00 AM, Zak Kohler <y...@y2kbugger.com> wrote:
> Yes, it is finding much more than just one error.
>
> From dmesg
> [89520.441354] BTRFS warning (device sdn): csum failed ino 4708 off
> 27529216 csum 2615801759 exp
Yes, it is finding much more than just one error.
>From dmesg
[89520.441354] BTRFS warning (device sdn): csum failed ino 4708 off
27529216 csum 2615801759 expected csum 874979996
$ sudo btrfs scrub start --offline --progress /dev/sdn
ERROR: data at bytenr 68431499264 mirror 1 csum mismatch, have
'$ sudo btrfs send /mnt/dataroot.2017.10.21/ | pv -i5 > /dev/null'
Does anyone know why scrub did not catch these errors that show up in dmesg?
On Mon, Oct 23, 2017 at 12:25 AM, Zak Kohler <y...@y2kbugger.com> wrote:
> Was attempting my first btrfs send receive over ssh and continuall
Was attempting my first btrfs send receive over ssh and continually
received ioctl error at different points but always in the first 3
minutes. The volume consists of three devices with only metadata
duplication. I narrowed down the error to the send command by
recreating the error while
