On Thursday 01 Oct 2015 13:36:50 Filipe Manana wrote: > 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. Sorry, I didn't know about the "Don't reuse subvol ids" heuristic. > 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. > Filipe, this approach looks good to me. I will write the V2 patch and send it to the mailing list. > >> 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 -- chandan -- 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
