Hi, Am 10.05.2017 um 09:48 schrieb Martin Steigerwald: > Stefan Priebe - Profihost AG - 10.05.17, 09:02: >> I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me >> something about the expected runtime or how to fix bad key ordering? > > I had a similar issue which remained unresolved. > But I clearly saw that btrfs check was running in a loop, see thread: > [4.9] btrfs check --repair looping over file extent discount errors > > So it would be interesting to see the exact output of btrfs check, maybe > there > is something like repeated numbers that also indicate a loop.
Output is just: enabling repair mode Checking filesystem on /dev/mapper/crypt_md0 UUID: 37b15dd8-b2e1-4585-98d0-cc0fa2a5a7c9 bad key ordering 39 40 checking extents [.] even after 2,5 weeks running. Stefan > I was about to say that BTRFS is production ready before this issue happened. > I still think it for a lot of setup mostly is, as at least the "I get stuck > on > the CPU while searching for free space" issue seems to be gone since about > anything between 4.5/4.6 kernels. I also think so regarding absence of data > loss. I was able to copy over all of the data I needed of the broken > filesystem. > > Yet, when it comes to btrfs check? Its still quite rudimentary if you ask me. > > So unless someone has a clever idea here and shares it with you, it may be > needed to backup anything you can from this filesystem and then start over > from > scratch. As to my past experience something like xfs_repair surpasses btrfs > check in the ability to actually fix broken filesystem by a great extent. > > Ciao, > -- 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
