| Message ID | 5174C426.3030204@redhat.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
yeah we should set the v2 parameter at all the place where we call btrfs_set_root_generation. Sorry it slipped my mind. Thanks for the fix. Thanks, Anand On 04/22/2013 01:01 PM, Eric Sandeen wrote: > With this integration branch commit in place: > > 2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck > > I started seeing generation mismatch messages from the kernel > at mount time, after a fresh mkfs(!): > > btrfs: mismatching generation and generation_v2 found in root item... > > This is because the code which emits the warning does not do so if > there is a mismatch but generation_v2 is 0; the above commit began > setting generation_v2 to something non-zero, so the warning was emitted. > > The reason there is a mismatch at all is because mkfs.btrfs calls > create_data_reloc_tree(), which copies a root, and then calls > btrfs_set_root_generation(), bumping the original copied generation. > But nothing updated generation_v2 to match on the way to disk. > > Fix this by updating generation_v2 in btrfs_insert_root(), > as is done in the kernel. > > This is safe because it's a new root created by userspace, so > the btrfs_root_item is guaranteed to be big enough to contain > generation_v2. > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> > --- > > Another example of why we need to get userspace in sync with kernelspace... > > diff --git a/root-tree.c b/root-tree.c > index 4454147..1823918 100644 > --- a/root-tree.c > +++ b/root-tree.c > @@ -105,6 +105,11 @@ int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root > *item) > { > int ret; > + > + /* > + * Make sure generation v1 and v2 match. See update_root for details. > + */ > + btrfs_set_root_generation_v2(item, btrfs_root_generation(item)); > ret = btrfs_insert_item(trans, root, key, item, sizeof(*item)); > return ret; > } > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/root-tree.c b/root-tree.c index 4454147..1823918 100644 --- a/root-tree.c +++ b/root-tree.c @@ -105,6 +105,11 @@ int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root *item) { int ret; + + /* + * Make sure generation v1 and v2 match. See update_root for details. + */ + btrfs_set_root_generation_v2(item, btrfs_root_generation(item)); ret = btrfs_insert_item(trans, root, key, item, sizeof(*item)); return ret; }
With this integration branch commit in place: 2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck I started seeing generation mismatch messages from the kernel at mount time, after a fresh mkfs(!): btrfs: mismatching generation and generation_v2 found in root item... This is because the code which emits the warning does not do so if there is a mismatch but generation_v2 is 0; the above commit began setting generation_v2 to something non-zero, so the warning was emitted. The reason there is a mismatch at all is because mkfs.btrfs calls create_data_reloc_tree(), which copies a root, and then calls btrfs_set_root_generation(), bumping the original copied generation. But nothing updated generation_v2 to match on the way to disk. Fix this by updating generation_v2 in btrfs_insert_root(), as is done in the kernel. This is safe because it's a new root created by userspace, so the btrfs_root_item is guaranteed to be big enough to contain generation_v2. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- Another example of why we need to get userspace in sync with kernelspace... -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html