On 20/11/13 17:08, Duncan wrote: > Martin posted on Wed, 20 Nov 2013 06:51:20 +0000 as excerpted: > >> It's now gone back to a pattern from a full week ago: >> >> (gdb) bt #0 0x000000000042d576 in read_extent_buffer () >> #1 0x000000000041ee79 in btrfs_check_node () >> #2 0x0000000000420211 in check_block () >> #3 0x0000000000420813 in btrfs_search_slot () >> #4 0x0000000000427bb4 in btrfs_read_block_groups () >> #5 0x0000000000423e40 in btrfs_setup_all_roots () >> #6 0x000000000042406d in __open_ctree_fd () >> #7 0x0000000000424126 in open_ctree_fs_info () >> #8 0x000000000041812e in cmd_check () >> #9 0x0000000000404904 in main () >> >> >> 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. > ( https://btrfs.wiki.kernel.org/index.php/FAQ , search on "hours". ) > > OK, so we round that to a day a TB, double for your two TB, and double > again in case your drive is much slower than the "normal" drive the > comment might have been considering and because that's for a balance but > you're doing a btrfsck --repair, which for all we know takes longer. > > That's still "only" four days, and you've been going well over a week. > At this point I think it's reasonably safe to conclude it's in some sort > of loop and likely will never finish. > ... but at a week a shot, there > comes a time when it's simply time to declare a loss and move on. Exactly so... No idea what btrfsck is so very slowly checking through or if it has indeed looped. Which is where progress output would be useful. However, btrfsck is rather too slow to be practical at the moment. Further development?... Any useful debug to be had from this case before I move on? Regards, Martin Still at: 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 ...which is all the output thus far. And: (gdb) bt #0 0x000000000042d574 in read_extent_buffer () #1 0x000000000041ee79 in btrfs_check_node () #2 0x0000000000420211 in check_block () #3 0x0000000000420813 in btrfs_search_slot () #4 0x0000000000427bb4 in btrfs_read_block_groups () #5 0x0000000000423e40 in btrfs_setup_all_roots () #6 0x000000000042406d in __open_ctree_fd () #7 0x0000000000424126 in open_ctree_fs_info () #8 0x000000000041812e in cmd_check () #9 0x0000000000404904 in main () -- 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
