On Sun, Jan 24, 2016 at 3:16 PM, Tom Hunt <tomdicksonhunt@xxxxxxxxx> wrote: > I get "currently mounted, aborting". > > If I must bring down the machine over this, I can, but I'd prefer not to. Now is a good time to refresh its backup, while it's online. It's also a good idea to maintain readonly snapshots of each subvolume you want to keep in case you need to depend on using btrfs send/receive to move the data to a new file system, since only ro snapshots can be used for send/receive. Maybe it's an orphaned item. I don't know much about those, whether btrfs check finds or removes them. But you can safely use btrfs-debug-tree while the fs is mounted. btrfs-debug-tree <dev> | grep -A3 -B3 ORPHAN That'd find object type ORPHAN and item type ORPHAN_ITEM. Again, no idea what to do about it if either are found, and matches inode 515. You could also do a search using btrfs-debug-tree <dev> | grep -A3 -B3 "(515 " and see if that reveals anything. While the fs has to be umounted for this, the --init-csum-tree option for btrfs check will obliterate the current csum tree (and all file csums) and then compute new csums for everything. That might fix it, at least if it's a stuck orphan item then this ought to give it a valid csum so you can proceed with conversion. -- 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
