$ 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
Mounting with degraded,ro does not fix the multi-device issue. The system was never really intended to have a second device, though: $ 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? 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
