On Sun, Jan 24, 2016 at 8:21 PM, Tom Hunt <tomdicksonhunt@xxxxxxxxx> wrote: > 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 I'm kinda out of ideas. A full balance at least is an online process, maybe it gets rid of the phantom missing inode reference. It'd be interesting to see what 'btrfs check' shows. If you decide to try --init-csum-tree, I'd first refresh a backup, and make current ro snapshots of things you'd send/receive, should it become necessary to create a new file system. > > 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. Yeah, very loose estimate is a btrfs-debug-tree output to a file is 1/4 of the metadata size reported by 'fi usage/df' although it could be much smaller if if you have a lot of small files with inline data extents. -- 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
