On Sat, Nov 11, 2017 at 11:27 AM, Zak Kohler wrote:
> It seems that since the errors were due to a very slight instability in
> computer due to overclock, the online and offline scrub's causing different
> stresses or paths. Could it be that one is telling the drives to use
On Sun, Oct 29, 2017 at 1:05 PM, Chris Murphy wrote:
> On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler wrote:
>
>> I will gladly repeat this process, but I am very concerned why this
>> corruption happened in the first place.
>
> Right. So everyone who
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
Duncan posted on Mon, 30 Oct 2017 04:09:58 + as excerpted:
> Zak Kohler posted on Sun, 29 Oct 2017 21:57:00 -0400 as excerpted:
>
>> So I ran memtest86+ 5.01 for >4 days:
>> Pass: 39 Errors: 0
>
> Be aware that memtest86+ will detect some types of errors but not
> others.
>
> In
On Mon, Oct 30, 2017 at 2:57 AM, Zak Kohler wrote:
> $ sudo btrfs scrub start --offline --progress /dev/disk/by-id/WD-XX1
> Scrub result:
> Tree bytes scrubbed: 5234425856
> Tree extents scrubbed: 638968
> Data bytes scrubbed: 4353723670528
> Data extents scrubbed: 374300
>
Lakshmipathi.G posted on Mon, Oct 30, 2017 at 12:07 AM as excerpted:
> Can you share these steps as simple bash script? Currently I'm running
> few tests, I can check your script and share the results.
sure, but it is pretty trivial:
device1=/dev/disk/by-id/XX1
device2=/dev/disk/by-id/XX2
Zak Kohler posted on Sun, 29 Oct 2017 21:57:00 -0400 as excerpted:
> So I ran memtest86+ 5.01 for >4 days:
> Pass: 39 Errors: 0
Be aware that memtest86+ will detect some types of errors but not others.
In particular, some years ago I had some memory (DDR1/3-digit-Opteron
era), actually
> I will gladly repeat this process, but I am very concerned why this
> corruption happened in the first place.
>
Can you share these steps as simple bash script? Currently I'm running
few tests, I can check your script and share the results.
> The only thing I could think of is that the btrfs
On Sun, Oct 29, 2017 at 3:05 PM, Chris Murphy wrote:
> On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler wrote:
>
>> I will gladly repeat this process, but I am very concerned why this
>> corruption happened in the first place.
>
> Right. So everyone who
On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler wrote:
> I will gladly repeat this process, but I am very concerned why this
> corruption happened in the first place.
Right. So everyone who can, needs to run the three scrubs on all
available Btrfs volumes/devices and see if they
I don't need to recover in this case. I can just remake the filesystem. I'm
just very concerned that this corruption was able to happen. Here is the entire
history of the filesystem:
2017.10.18 create btrfs from 3 drives aka OfflineJ and rsync
data from old madam raid5
1. I guess you should be able to dump tree details via
'btrfs-debug-tree' and then map the extent/data (from scrub
offline output) and track it back to inode-object. Store output of
both btrfs-debug-tree and scrub-offline in different files and then
play around with grep to extract required data.
I apologize for the bad line wrapping on the last post...will be
setting up mutt soon.
This is the final result for the offline scrub:
Doing offline scrub [O] [681/683]
Scrub result:
Tree bytes scrubbed: 5234491392
Tree extents scrubbed: 638975
Data bytes scrubbed: 4353723572224
Data extents
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
> Does anyone know why scrub did not catch these errors that show up in dmesg?
Can you try offline scrub from this repo
https://github.com/gujx2017/btrfs-progs/tree/offline_scrub and see
whether it
detects the issue? "btrfs scrub start --offline "
Cheers,
Lakshmipathi.G
All three devices completed the 'long' SMART selftest without error:
# 1 Extended offlineCompleted without error 00%
Here is the standard data that I forgot to include in my first message:
Running Arch linux
$ uname -a
Linux HOSTNAME 4.9.56-1-lts #1 SMP Thu Oct 12 22:34:15 CEST 2017
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
17 matches
Mail list logo