Okay, I will rebuild it then. Thank you. Where do I add -p?
On Sat, Jan 2, 2016, at 10:28 PM, Chris Murphy wrote: > On Sat, Jan 2, 2016 at 1:39 PM, Rasmus Abrahamsen <bt...@rasmusa.net> > 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 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
