On Mon, Jun 20, 2016 at 3:22 AM, Tyson Whitehead <twhiteh...@gmail.com> wrote: > On 17/06/16 06:18 PM, Chris Murphy wrote: >> >> On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead <twhiteh...@gmail.com> >> wrote: >>> >>> On May 27, 2016 12:12:54 PM Chris Murphy wrote: >>>> >>>> On Thu, May 26, 2016 at 11:55 AM, Tyson Whitehead <twhiteh...@gmail.com> >>>> wrote: >>>>> >>>>> Under the last several kernels versions (4.6 and I believe 4.4 and, >>>>> 4.5) btrfs scrub aborts before completing. >>>> >>>> >>>> I can't reproduce this with btrfs-progs 4.5.2 and kernel 4.6.0. >>>> >>>> I think the bigger issue is the lack of information why a scrub is >>>> aborted. >>> >>> >>> Thanks for checking into this Chris. >>> >>> Any advice on how to get some more information out of the scrub process? >> >> >> Next you need to find out why this one device has so many errors. Put the >> output from smartctl -x /dev/sdb somewhere, maybe even attach it to the bug >> report since it's somewhat related. Either that device is simply unreliable, >> or you've got a bad cable connection. > > > The device is okay. The errors were caused by me running it for a period > with only one of the devices present. > > In more detail. My desktop has a BTRFS RAID 1 setup. I needed to access to > it on the road, so I just shut the desktop down, grabbed one of the drives, > and used it in my laptop in degraded mode. > > When I got back I recombined them (the one I left in my office was never > booted by itself) and started a scrub. That is when I discovered scrub > aborted on newer kernels but completed okay on older ones. > > Cheers! -Tyson
Are you absolutely positively certain that only one of the two devices was ever written to while mounted degraded? As in you're 100% certain, not 99% or less certain? -- Chris Murphy -- 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://vger.kernel.org/majordomo-info.html
