The only output from btrfs-debug-tree containing ORPHAN:
item 151 key (ORPHAN ORPHAN_ITEM 150415) itemoff 4904 itemsize 0
orphan item
item 152 key (ORPHAN ORPHAN_ITEM 150416) itemoff 4904 itemsize 0
orphan item
item 153 key (ORPHAN ORPHAN_ITEM 175228) itemoff 4904 itemsize 0
orphan item
item 154 key (ORPHAN ORPHAN_ITEM 175229) itemoff 4904 itemsize 0
orphan item
Given the later talk about orphans, I don't think this is an orphan; the disks
are new, and I know the checksum error issues came from running with bad RAM,
which has since been replaced.
The output referring to 515:
item 49 key (515 INODE_ITEM 0) itemoff 10851 itemsize 160
inode generation 132 transid 132 size 262144 nbytes 4194304
block group 0 mode 100600 links 1 uid 0 gid 0
rdev 0 flags 0x1b
item 50 key (515 EXTENT_DATA 0) itemoff 10798 itemsize 53
extent data disk byte 603428720640 nr 262144
extent data offset 0 nr 262144 ram 262144
extent compression 0
Incidentally, btrfs-debug-tree produced about 1.5G of text output; I'm not sure
whether that's normal for a 6TB volume with ~4TB used, or what.
On Sun, Jan 24, 2016 at 03:45:49PM -0700, Chris Murphy wrote:
> 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
--
Tom Hunt
--
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
