Small correction,I was just hit by this:
> # The tuple (inode_number, inode generation) is unique within a
> particular btrfs subvolume. Inode numbers can be reused via
> "inode_cache" mount option if it is set, however, same inode number
> (after deletion of previous one) will have another inode generation if
> it is reused. The changed_inode function determines this case by
> setting cur_inode_new_gen flag. In that case it knows, that this is
> not the same inode that was just changed, so it needs to delete the
> old inode and create a new one. If you ignore this case at first (say
> you don't use inode_cache), then this function becomes pretty simple.
Even if "inode_cache" mount option is not used, inode number still can
be reused!
Looking at btrfs_find_free_objectid():
if (unlikely(root->highest_objectid < BTRFS_FIRST_FREE_OBJECTID)) {
ret = btrfs_find_highest_objectid(root,
&root->highest_objectid);
if (ret)
goto out;
}
So after mount root->highest_objectid is set to 0, and later
initialized on-demand. So the scenario to reuse the inode number is as
follows:
# mount the filesystem
# delete the file that has the highest inode number
# create a new file
At this point the new file will get the same inode number. Amazing!
Alex.
--
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
