>>>> I don't know if that has gone through that pattern during the week but >>>> at a-week-a-time, this is not going to finish in reasonable time. >>>> >>>> How come so very slow? >>>> >>>> Any hints/tips/fixes or abandon the test? >>> >>> You're a patient man. =:^) >> >> Sort of... I can leave it running in the background until I come to need >> to do something else with that machine. So... A bit of an experiment. > > > Until... No more... And just as the gdb bt shows something a little > different! > > (gdb) bt > #0 0x000000000041ddc4 in btrfs_comp_keys () > #1 0x00000000004208e9 in btrfs_search_slot () > #2 0x0000000000427bb4 in btrfs_read_block_groups () > #3 0x0000000000423e40 in btrfs_setup_all_roots () > #4 0x000000000042406d in __open_ctree_fd () > #5 0x0000000000424126 in open_ctree_fs_info () > #6 0x000000000041812e in cmd_check () > #7 0x0000000000404904 in main () > > > Nearly done or weeks yet more to run? > > The poor thing gets killed in the morning for new work.
OK, so that all came to naught and it got killed for a kernel update and new work. "Just for a giggle," I tried mounting that disk with the 'recovery' option and it failed with the usual complaint: btrfs: disabling disk space caching btrfs: enabling auto recovery parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 btrfs: open_ctree failed Trying a wild guess of "btrfs-zero-log /dev/sdc" gives: parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 parent transid verify failed on 911904604160 wanted 17448 found 17450 Ignoring transid failure ... and it is sat there at 100% CPU usage, no further output, and no apparent disk activity... Just like btrfsck was... So... Looks like time finally for a reformat. Any chance of outputting some indication of progress, and for a speedup, or options for partial recovery or?... Or for a fast 'slash-and-burn' recovery where damaged trees get cleanly amputated rather than too-painfully-slowly repaired?... Just a few wild ideas ;-) Regards, Martin -- 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
