Just curious, would the observed behavior change if one modifies head in any way between snap and umount? Regards, Andrey > > 02.12.2011 13:28 пользователь "Jan Schmidt" <list.btrfs@xxxxxxxxxxxxx> > написал: > > > 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. > > 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 > -- > 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 -- 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
