Skip to contentSkip to conversation

btrfsck: unresolved ref root

DISCUSSION Jan Schmidt 2 participants 2 messages Dec 2, 2011 1 message not in the archive Btrfs file system

lore
Share & tools
lore
#0 lore raw

While hunting another bug, I got distracted by btrfsck error output, which is reproducible as simple as creating a snapshot. Either btrfsck is strange or subvolume snapsnot does something wrong.

# mkfs.btrfs /dev/sdo
# mount /dev/sdo /mnt/scratch/
# umount /mnt/scratch/
# btrfsck /dev/sdo

-> everything ok

# mount /dev/sdo /mnt/scratch/
# btrfs subvol snap /mnt/scratch/ /mnt/scratch/snap1
# umount /mnt/scratch
# btrfsck /dev/sdo
fs tree 257 refs 2
        unresolved ref root 257 dir 256 index 2 namelen 5 name snap1
error 600
[...]

Tested with current for-linus and most current btrfsck. I also have older filesystems with snapshots I never used on btrfsck before, they also show the "unresolved ref" error.

Quoted 1 line

From a quick look at the btrfsck code, this complaint means that btrfsck

is looking for two BTRFS_ROOT_REF_KEY and BTRFS_ROOT_BACKREF_KEY each in the tree of tree roots. However there's only one of each (as I would expect):

item 4 key (FS_TREE ROOT_REF 257) itemoff 3238 itemsize 23
root ref key dirid 256 sequence 2 name snap1
...
item 12 key (257 ROOT_BACKREF 5) itemoff 2315 itemsize 23
root backref key dirid 256 sequence 2 name snap1

-Jan

A message that is not in the archive (sent off-list or not yet received): CANvN+enynzy=y3-vXDNHB4oFBjBZOTxwx9AvB+suoRkCsDwcwQ@mail.gmail.com

#2 lore raw

Just curious, would the observed behavior change if one modifies head i= n any
way between snap and umount?

Regards,
Andrey

Quoted 2 lines

02.12.2011 13:28 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=

=D0=B5=D0=BB=D1=8C "Jan Schmidt" <[email protected]>

Quoted 5 lines

=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

While hunting another bug, I got distracted by btrfsck error output, which is reproducible as simple as creating a snapshot. Either btrfsc=

k

Quoted 7 lines

is strange or subvolume snapsnot does something wrong.

# mkfs.btrfs /dev/sdo
# mount /dev/sdo /mnt/scratch/
# umount /mnt/scratch/
# btrfsck /dev/sdo
Quoted 8 lines

-> everything ok

# mount /dev/sdo /mnt/scratch/
# btrfs subvol snap /mnt/scratch/ /mnt/scratch/snap1
# umount /mnt/scratch
# btrfsck /dev/sdo
fs tree 257 refs 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0unresolved ref root 257 dir 256 index 2 na=

melen 5 name snap1

Quoted 8 lines

error 600
[...]

Tested with current for-linus and most current btrfsck. I also have older filesystems with snapshots I never used on btrfsck before, they also show the "unresolved ref" error.

From a quick look at the btrfsck code, this complaint means that btrf=

sck

Quoted 1 line

is looking for two BTRFS_ROOT_REF_KEY and BTRFS_ROOT_BACKREF_KEY each=

in

Quoted 4 lines

the tree of tree roots. However there's only one of each (as I would expect):

=C2=A0 =C2=A0 =C2=A0 =C2=A0item 4 key (FS_TREE ROOT_REF 257) itemoff =

3238 itemsize 23

Quoted 1 line

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root ref key d=

irid 256 sequence 2 name snap1

Quoted 2 lines

...
=C2=A0 =C2=A0 =C2=A0 =C2=A0item 12 key (257 ROOT_BACKREF 5) itemoff 2=

315 itemsize 23

Quoted 1 line

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root backref k=

ey dirid 256 sequence 2 name snap1

Quoted 4 lines

-Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=

" in

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=

ml
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html