$ sudo btrfs check -r 1085440000 /dev/sda4 parent transid verify failed on 1085440000 wanted 325966 found 325709 parent transid verify failed on 1085440000 wanted 325966 found 325709 Ignoring transid failure bytenr mismatch, want=61352312832, have=0 Couldn't setup device tree ERROR: cannot open file system
On Fri, Aug 18, 2017 at 5:19 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2017年08月18日 17:08, Zirconium Hacker wrote: >> >> I already ran that earlier, here's the pastebin: >> https://pastebin.com/KGB8nVRA >> >> Running debug-tree on all 1084 of them (I guess that was unnecessary) >> gave the same errors every time: >> bytenr mismatch, want=61809344512, have=0 >> Couldn't read tree root >> ERROR: unable to open /dev/sda4 >> > > Then try using btrfs check with new root: > > # btrfs check -r 1085440000 /dev/sda4 > > Please note that, the generation in superblock differs quite a lot with > find-root result. > So I'm afraid it will cause quite a lot of problems. > > But least, it should help btrfs check to get over "Couldn't read tree root" > error message. > > And for btrfs-debug-tree error, I'll submit a patch soon to allow it to be > run on such heavily damaged fs. > > > Thanks, > Qu > >> On Fri, Aug 18, 2017 at 5:03 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: >>> >>> >>> >>> On 2017年08月18日 16:47, Zirconium Hacker wrote: >>>> >>>> >>>> $ sudo btrfs-debug-tree -b 131072 /dev/sda4 >>>> btrfs-progs v4.12 >>>> bytenr mismatch, want=61809344512, have=0 >>>> Couldn't read tree root >>>> ERROR: unable to open /dev/sda4 >>> >>> >>> >>> I think this can be improved for case like this. >>> I'll try to submit a patch to enhance btrfs-debug-tree. >>> >>> Would you please try "btrfs-find-root /dev/sda4"? >>> This will try to locate on-disk old tree root, and if we're lucky, old >>> tree >>> root can allow us to mount the fs. >>> >>>> >>>> Mounting with degraded,ro does not fix the multi-device issue. The >>>> system was never really intended to have a second device, though: >>> >>> >>> >>> Wait for a minute, did you mean this btrfs doesn't ever have a second >>> device? >>> This seems quite weird now. >>> >>>> >>>> $ sudo btrfs fi show /dev/sda4 >>>> bytenr mismatch, want=61809344512, have=0 >>>> Couldn't read tree root >>>> Label: none uuid: 29889b3a-1c10-48e4-ad6d-21d03d06e90b >>>> Total devices 2 FS bytes used 49.52GiB >>>> devid 1 size 54.07GiB used 54.07GiB path /dev/sda4 >>>> *** Some devices missing >>>> >>>> I vaguely remember following this guide at some point: >>>> >>>> >>>> http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html >>>> -- specifically the "Balance cannot run because the filesystem is >>>> full" part. This may have broken some things? >>> >>> >>> >>> Not sure, at least from your superblock, too many things are in doubt. >>> From the number of devices, to strange system chunk. >>> >>> >>> Thanks, >>> Qu >>>> >>>> >>>> >>>> On Fri, Aug 18, 2017 at 4:15 AM, Qu Wenruo <quwenruo.bt...@gmx.com> >>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On 2017年08月18日 15:17, Zirconium Hacker wrote: >>>>>> >>>>>> >>>>>> >>>>>> I checked my fstab, and my mount options for that partition are: >>>>>> nodev,nosuid (so no discard). >>>>>> As far as I remember, I had some issues converting from ext4 with >>>>>> existing tools (I think that was on Debian so the tools were likely >>>>>> older) so I did a manual conversion backup, wipe, copy files back). >>>>>> >>>>>> $ sudo btrfs-find-root -o 3 /dev/sda4 >>>>>> Couldn't read tree root >>>>>> Superblock thinks the generation is 311252 >>>>>> Superblock thinks the level is 0 >>>>>> ERROR: tree block bytenr 0 is not aligned to sectorsize 4096 >>>>>> Found tree root at 131072 gen 311252 level 0 >>>>> >>>>> >>>>> >>>>> >>>>> So chunk root (and since it's level 0, the whole chunk tree) seems >>>>> good. >>>>> >>>>> Could you please try the following command? >>>>> # btrfs-debug-tree -b 131072 /dev/sda4 >>>>> >>>>> I assume it may fail due to the fact that root tree is corrupted. >>>>> But maybe we are lucky? >>>>> >>>>> >>>>> And further investigating your super dump and the code, it's shows some >>>>> clue, mostly related to your multi-device setup. >>>>> >>>>> Your find-root output shows that, the only chunk leaf in /dev/sda4 >>>>> seems >>>>> good. >>>>> And in btrfs_read_chunk_tree(), which returned -EIO and caused the >>>>> error >>>>> message, will first search chunk root. >>>>> >>>>> Since your chunk leaf is good, such search itself should not cause too >>>>> much >>>>> problem. >>>>> >>>>> Then btrfs_read_chunk_tree() will try to read out each device, by >>>>> calling >>>>> read_one_dev(). >>>>> Which can return -EIO if any device is missing and you're not using >>>>> degraded >>>>> mount option. >>>>> >>>>> Is your 2nd device missing? If so, would you please try to mount with >>>>> "degraded,ro" mount option? >>>>> >>>>> BTW, if you didn't manually convert chunk profiles, did you first >>>>> create >>>>> btrfs on single device, and then added a new device to the btrfs? >>>>> >>>>> Thanks, >>>>> Qu >>>>> >>>>>> >>>>>> On Fri, Aug 18, 2017 at 12:10 AM, Chris Murphy >>>>>> <li...@colorremedies.com> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 17, 2017 at 4:42 PM, Qu Wenruo <quwenruo.bt...@gmx.com> >>>>>>> wrote: >>>>>>> >>>>>>>> BTW are you using discard mount option? Sometimes it can cause >>>>>>>> problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> OP did not say if it was using discard mount option; but did say some >>>>>>> time before this (I'm not sure how recent) he had used fstrim. The >>>>>>> firmware for this SSD model is current. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>> > -- 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
