Sounds like you think my best bet is to re-roll my filesystem instead of attempt to repair it. Is that right?
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? On Sat, Jan 2, 2016, at 09:32 PM, Chris Murphy wrote: > On Sat, Jan 2, 2016 at 1:15 PM, Chris Murphy <li...@colorremedies.com> > wrote: > > On Sat, Jan 2, 2016 at 12:58 PM, Rasmus Abrahamsen <bt...@rasmusa.net> > > wrote: > >> What do you recommend I do? Everything is redundant across disks. > >> Perhaps I can disconnect the one you mentioned and delete missing. > > > > No, please stop trying new things like throwing spaghetti at a wall. > > The file system is not healthy or it wouldn't behave the way it is. If > > you have a current backup, and want to keep playing to see how bad > > it'll get, then keep proceeding. > > > > But if you have any important data on this volume that you don't have > > a current backup for, then you need to make as few changes as > > possible. Don't delete devices. Don't run btrfsck. Don't scrub. Don't > > balance. Just try to get it mounted first, and then btrfs send, rsync, > > or cp the data you need off the volume onto a new volume. > > That means try a normal mount with no mount options first. If that > doesn't work then try: > > -o recovery > -o ro,recovery > -o ro,recovery,degraded > > If you can get it rw mounted, then you maybe can make ro snapshots > that you can send/receive to a new Btrfs file system. Or rsync -a or > cp -a to a new other file system. > > If you can't get it rw mounted, and don't already have ro snapshots of > the things you want, then you'll have to use rsync or cp. > > > -- > 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
