Btrfs Scrub - scheduled task got cancelled - no reason being displayed?

glenngould · January 15, 2018, 10:55am

@phillxnet thx. I’m running on 3.9.2-10
The output gives still the same number or error as posted earlier

[root@rockstor ~]# btrfs scrub status -R /mnt2/rm_pool
scrub status for d5829eb2-f19f-4329-83a4-c71261a270bf
        scrub started at Fri Jan 12 08:00:01 2018 and was aborted after 00:11:27
        data_extents_scrubbed: 1171564
        tree_extents_scrubbed: 102989
        data_bytes_scrubbed: 76696776704
        tree_bytes_scrubbed: 1687371776
        read_errors: 24
        csum_errors: 4
        verify_errors: 0
        no_csum: 0
        csum_discards: 0
        super_errors: 0
        malloc_errors: 0
        uncorrectable_errors: 28
        unverified_errors: 0
        corrected_errors: 0
        last_physical: 118165733376

phillxnet · January 15, 2018, 11:12am

@glenngould Thanks, so I think I may have misread your question.

I had assumed you were querying Rockstor’s interpretatin of the last scrub state but in that regard all looks to be OK. That is Rockstor translates “aborted” in that first info line to “cancelled”:

github.com

rockstor/rockstor-core/blob/master/src/rockstor/fs/btrfs.py#L1163-L1170


elif re.search('aborted', out[1]) is not None:
    stats['status'] = 'cancelled'
    # extract the duration from the end of the first line eg:
    # "... 2017 and was aborted after 00:04:56"
    # TODO: we have code duplication here re finished clause above.
    dfields = out[1].split()[-1].split(':')
    stats['duration'] = ((int(dfields[0]) * 60 * 60) +
                         (int(dfields[1]) * 60) + int(dfields[2]))

So in that regard we are good on the reporting. Out of interest re the scrub details report is that also represented correctly in the summary and the detail?

Assuming your question is actually down to why this scrub was aborted I’ll leave that to others more experienced in btrfs scrub abort reasons. I can say that if the scrub was interrupted, for example by a power cycle, then it would show as ‘interrupted’ in that output, which is translated by the Rockstor UI into ‘halted’ (further up in the quoted piece of code).

Essentially you have a correct report by Rockstor UI of the last scrub state as reported by btrfs itself.

As a double check on your installed Rockstor version could you also post the output of:

yum info rockstor

Not really related in your case but best to check as we had a catch 22 bug recently in reported installed Rockstor version.

Hope that helps.

glenngould · January 15, 2018, 11:31am

@phillxnet Rockstor version 3.9.2-10 is confirmed by yum info rockstor

So I need to hope and see if there is another expierenced btrfs user here who could help me what to do with those uncorrectable errors which might be the issue why the scrub task gets cancelled everytime…

thx

Haioken · January 16, 2018, 12:13pm

@glenngould

As the issue seems to be related to btrfs more than Rockstor, you might try the btrfs mailing list, or the btrfs subreddit, you’re likely to find information on complicated btrfs issues more readily available there.

glenngould · January 16, 2018, 12:32pm

@Haioken thx, I’ve tried already once but got lost in space…
I need to sit down and spend more time I guess

Hooverdan · January 16, 2018, 11:56pm

I’m not that experienced in btrfs, but I had uncorrectable errors as well. Based on some forum recommendations I ran memtest on that machine, and after a 12hr test cycle found a bad memory stick. So, this was more after the fact, but since I had replaced the memory stick, I have not had a failed scrub. Mind you, the errors I had “created” that the scrub found were likely based on memory messing up some previous write operations, which the scrub then found and couldn’t recover…