On Sat, Jan 2, 2016 at 1:39 PM, Rasmus Abrahamsen <btrfs@xxxxxxxxxxx> wrote: > Sounds like you think my best bet is to re-roll my filesystem instead of > attempt to repair it. Is that right? If you want to get back to a working fs as soon as possible, yes. You could take a btrfs-image of it first; if that fails you can use btrfs-debug-tree. Both of those should direct the output to a file on another file system. Maybe a dev will find it useful? And then if you want you can keep trying to repair it, but my experience is that in such cases the fs quickly is in the weeds and is beyond repair even when it's possible to ro mount or use restore to get all data out. > I have snapshots which are based on each other as a backup of a remote > machine by date. By sending these snapshots to a new filesystem, will I > be able to have them still be incremental and save space? Yes, the first one without -p is the big send. Then each additional one uses the most immediate previous snapshot with -p. I haven't tried the -e option with multiple increments, so I don't know if that works or if it's expected to work. I'm having to do this right now myself with an imploded raid1 that won't mount so I might find out in the next hour or two if -e works. -- 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
