On Thu, Oct 1, 2015 at 12:57 PM, David Sterba <dsterba@xxxxxxx> wrote: > On Thu, Oct 01, 2015 at 04:19:55PM +0530, Chandan Rajendra wrote: >> This occurs because, >> >> Mount filesystem >> Create subvol with ID 257 >> Unmount filesystem >> Mount filesystem >> Delete subvol with ID 257 >> btrfs_drop_snapshot() >> Add root corresponding to subvol 257 into >> btrfs_transaction->dropped_roots list >> Create new subvol (i.e. create_subvol()) >> 257 is returned as the next free objectid > > How is this possible? We do not intentionally reuse the subvol ids so > this means that the bug is in the id assignment code. Very simple. Just look at inode-map.c's btrfs_find_free_objectid and btrfs_find_highest_objectid... As long as the deleted subvolume as the highest object id and before deleting it no one called btrfs_find_free_objectid() against the root of tree roots. If we do the initialization of a root's highest object id when we load the root, instead of when we need to get an object id, the problem shouldn't happen anymore. > >> btrfs_read_fs_root_no_name() >> Finds the btrfs_root instance corresponding to the old subvol with ID 257 >> in btrfs_fs_info->fs_roots_radix. >> Returns error since btrfs_root_item->refs has the value of 0. > -- > 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 -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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
