THANK YOU ALL! I just had to truncate the first 1.5 KiB of the image file to get the offsets right (God knows why), but I could then get the btrfs driver to recognize it, and I could MOUNT THE FILESYSTEM! I'm going to run btrfs check on it, free some space on it, PROPERLY remove the extra device, and then boot the system and set up both more cloud backups and probably throw in a 500GB disk I have laying around so I can set up snapshots. Everyone has been very helpful, and sorry for the real issue being my own stupidity. :) On Fri, Aug 18, 2017 at 10:28 PM, Zirconium Hacker <jared.e.vb@xxxxxxxxx> wrote: > The image doesn't have a valid superblock. I'm really confused as to > how that could've happened. > > On Fri, Aug 18, 2017 at 7:21 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> On 2017年08月19日 05:52, Zirconium Hacker wrote: >>> >>> Ok, so since it's clear now that I need that 5 GB device to be >>> present... I found the image file. But how do I get BTRFS to >>> recognize the image as a device? >> >> >> # losetup -f >> Remember the loop*, here use /dev/loop1 as example. >> >> # losetup /dev/loop1 <your image> >> # partprobe /dev/loop1 >> Then you should have /dev/loop1p1 >> >> # btrfs dev rescan >> If nothing wrong happened, you should be good to go. >> >> Thanks, >> Qu >> >> >>> I have zero experience with >>> multi-device systems. Setting it up as a loop device doesn't fix >>> mounting, and wipefs doesn't detect the BTRFS magic number, but >>> printing some of it to console shows it does have real data. Writing >>> the magic number onto it (it's a copy of the original to be safe) >>> shows in dump-super, but all other values are zero. >>> >>> I tried sending the above on my phone earlier but it was detected as a >>> "virus" because it contained HTML. Whoops. >>> >>> On Fri, Aug 18, 2017 at 11:00 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> >>> wrote: >>>> >>>> On Fri, Aug 18, 2017 at 2:47 AM, Zirconium Hacker <jared.e.vb@xxxxxxxxx> >>>> wrote: >>>> >>>>> 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? >>>>> >>>> >>>> If you don't do 'btrfs device delete /dev/loop0' or if that command >>>> does not complete, then it's possible to get into the situation you're >>>> in. >>>> >>>> Have you ever mounted this file system with -o degraded? >>>> >>>> I'm going to guess the history is something like: >>>> 1. enospc >>>> 2. btrfs dev add >>>> 3. some kind of filtered balance, which only causes data block groups >>>> to be moved to the 2nd device >>>> 4. 2nd device is physically removed without first 'btrfs dev del' >>>> >>>> Zirco's superblock very clearly says num_devices 2, so I'd expect >>>> normal mount to always fail unless both devices are present. Is there >>>> some weird edge case where Btrfs might permit non-degraded mount when >>>> only data bg's are on a 2nd device? And then trouble only happens >>>> later when a balance is done and it goes looking for these bg's? And >>>> then, boom! >>>> >>>> -- >>>> Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
