Re: Chicken-egg: uncorrectable checksum error prevents RAID1 rebalancing

[Tom Hunt <tomdicksonhunt@gmail.com>]

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@gmail.com> 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