btrfs-progs: find-root: Fix wrong generation for log tree

PATCH In review Qu Wenruo 4 participants 10 messages Oct 12, 2018 – Oct 25, 2018 Btrfs file system

lore

Share & tools

lore

Qu Wenruo

author

2018-10-12 06:43 UTC #0 lore raw

PATCH 1/2 btrfs-progs: find-root: Fix wrong generation for log tree

When searching for log tree, we should use btrfs_super_generation + 1 other than log_root_transid.

Since log_root_transid is never touched and will be deprecated soon.

Signed-off-by Qu Wenruo <[email protected]>

---
 btrfs-find-root.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

btrfs-find-root.c +1 -1

index e2d2e70c408c..376bbc4c47fa 100644
@@ -73,7 +73,7 @@ static void get_root_gen_and_level(u64 objectid, struct btrfs_fs_info *fs_info,
 		break;
 	case BTRFS_TREE_LOG_OBJECTID:
 		level = btrfs_super_log_root_level(super);
-		gen = btrfs_super_log_root_transid(super);
+		gen = btrfs_super_generation(super) + 1;
 		break;
 	case BTRFS_UUID_TREE_OBJECTID:
 		gen = btrfs_super_uuid_tree_generation(super);

Signature · 1 line

2.19.1

Qu Wenruo

author

2018-10-12 06:43 UTC #1 lore raw

PATCH 2/2 btrfs-progs: Deprecate unused super block member log_root_transid

The only user of it is "btrfs inspect dump-super".

Signed-off-by Qu Wenruo <[email protected]>

---
 cmds-inspect-dump-super.c | 4 ++--
 ctree.h                   | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)

cmds-inspect-dump-super.c +2 -2

index e965267c5d96..3f33931ed9bc 100644
@@ -387,8 +387,8 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
 	       (unsigned long long)btrfs_super_chunk_root_level(sb));
 	printf("log_root\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root(sb));
-	printf("log_root_transid\t%llu\n",
-	       (unsigned long long)btrfs_super_log_root_transid(sb));
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
 	printf("log_root_level\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root_level(sb));
 	printf("total_bytes\t\t%llu\n",

ctree.h +2 -4

index 4719962df67d..a314fdb102b0 100644
@@ -427,8 +427,8 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	/* This member is never touched, should always be 0 */
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;

@@ -2203,8 +2203,6 @@ BTRFS_SETGET_STACK_FUNCS(super_chunk_root_level, struct btrfs_super_block,
 			 chunk_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_log_root, struct btrfs_super_block,
 			 log_root, 64);
-BTRFS_SETGET_STACK_FUNCS(super_log_root_transid, struct btrfs_super_block,
-			 log_root_transid, 64);
 BTRFS_SETGET_STACK_FUNCS(super_log_root_level, struct btrfs_super_block,
 			 log_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_total_bytes, struct btrfs_super_block,

Signature · 1 line

2.19.1

Nikolay Borisov

2018-10-12 06:53 UTC #2 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 13 lines · Qu Wenruo

The only user of it is "btrfs inspect dump-super".
Signed-off-by Qu Wenruo <[email protected]>
---
 cmds-inspect-dump-super.c | 4 ++--
 ctree.h                   | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)
cmds-inspect-dump-super.c +0 -0
index e965267c5d96..3f33931ed9bc 100644

cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391

Quoted 7 lines

cmds-inspect-dump-super.c +2 -2

@@ -387,8 +387,8 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
 	       (unsigned long long)btrfs_super_chunk_root_level(sb));
 	printf("log_root\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root(sb));
-	printf("log_root_transid\t%llu\n",
-	       (unsigned long long)btrfs_super_log_root_transid(sb));
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));

This should be entirely removed.

Quoted 28 lines

cmds-inspect-dump-super.c +0 -0

 	printf("log_root_level\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root_level(sb));
 	printf("total_bytes\t\t%llu\n",

ctree.h +2 -4

index 4719962df67d..a314fdb102b0 100644
@@ -427,8 +427,8 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	/* This member is never touched, should always be 0 */
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;

@@ -2203,8 +2203,6 @@ BTRFS_SETGET_STACK_FUNCS(super_chunk_root_level, struct btrfs_super_block,
 			 chunk_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_log_root, struct btrfs_super_block,
 			 log_root, 64);
-BTRFS_SETGET_STACK_FUNCS(super_log_root_transid, struct btrfs_super_block,
-			 log_root_transid, 64);
 BTRFS_SETGET_STACK_FUNCS(super_log_root_level, struct btrfs_super_block,
 			 log_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_total_bytes, struct btrfs_super_block,

Qu Wenruo

2018-10-12 08:47 UTC #3 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 11 lines · Nikolay Borisov

Quoted 8 lines · Qu Wenruo
The only user of it is "btrfs inspect dump-super".
Signed-off-by Qu Wenruo <[email protected]>
---
 cmds-inspect-dump-super.c | 4 ++--
 ctree.h                   | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)

Quoted 14 lines

cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391

Quoted 12 lines

cmds-inspect-dump-super.c +2 -2

index e965267c5d96..3f33931ed9bc 100644
@@ -387,8 +387,8 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
 	       (unsigned long long)btrfs_super_chunk_root_level(sb));
 	printf("log_root\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root(sb));
-	printf("log_root_transid\t%llu\n",
-	       (unsigned long long)btrfs_super_log_root_transid(sb));
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));

This should be entirely removed.

It looks OK to me.
Just like the old leafsize.

And if we try to use this member again, even old progs could show it without problem.

Thanks,
Qu

Quoted 29 lines

cmds-inspect-dump-super.c +0 -0

 	printf("log_root_level\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root_level(sb));
 	printf("total_bytes\t\t%llu\n",

ctree.h +2 -4

index 4719962df67d..a314fdb102b0 100644
@@ -427,8 +427,8 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	/* This member is never touched, should always be 0 */
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;

@@ -2203,8 +2203,6 @@ BTRFS_SETGET_STACK_FUNCS(super_chunk_root_level, struct btrfs_super_block,
 			 chunk_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_log_root, struct btrfs_super_block,
 			 log_root, 64);
-BTRFS_SETGET_STACK_FUNCS(super_log_root_transid, struct btrfs_super_block,
-			 log_root_transid, 64);
 BTRFS_SETGET_STACK_FUNCS(super_log_root_level, struct btrfs_super_block,
 			 log_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_total_bytes, struct btrfs_super_block,

Nikolay Borisov

2018-10-12 09:13 UTC #4 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 29 lines · Qu Wenruo

Quoted 11 lines · Nikolay Borisov
Quoted 8 lines · Qu Wenruo
The only user of it is "btrfs inspect dump-super".
Signed-off-by Qu Wenruo <[email protected]>
---
 cmds-inspect-dump-super.c | 4 ++--
 ctree.h                   | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)
Quoted 14 lines
cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391
Quoted 12 lines
cmds-inspect-dump-super.c +2 -2
index e965267c5d96..3f33931ed9bc 100644
@@ -387,8 +387,8 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
 	       (unsigned long long)btrfs_super_chunk_root_level(sb));
 	printf("log_root\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root(sb));
-	printf("log_root_transid\t%llu\n",
-	       (unsigned long long)btrfs_super_log_root_transid(sb));
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.

Quoted 5 lines

It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.

But what is the point of having something which always shows 0 and is essentially unused?

Quoted 34 lines

Thanks,
Qu

Quoted 29 lines

cmds-inspect-dump-super.c +0 -0

 	printf("log_root_level\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root_level(sb));
 	printf("total_bytes\t\t%llu\n",

ctree.h +2 -4

index 4719962df67d..a314fdb102b0 100644
@@ -427,8 +427,8 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	/* This member is never touched, should always be 0 */
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;

@@ -2203,8 +2203,6 @@ BTRFS_SETGET_STACK_FUNCS(super_chunk_root_level, struct btrfs_super_block,
 			 chunk_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_log_root, struct btrfs_super_block,
 			 log_root, 64);
-BTRFS_SETGET_STACK_FUNCS(super_log_root_transid, struct btrfs_super_block,
-			 log_root_transid, 64);
 BTRFS_SETGET_STACK_FUNCS(super_log_root_level, struct btrfs_super_block,
 			 log_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_total_bytes, struct btrfs_super_block,

Qu Wenruo

2018-10-12 09:57 UTC #5 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 32 lines · Nikolay Borisov

Quoted 29 lines · Qu Wenruo
Quoted 25 lines · Nikolay Borisov
Quoted 13 lines · Qu Wenruo
The only user of it is "btrfs inspect dump-super".
Signed-off-by Qu Wenruo <[email protected]>
---
 cmds-inspect-dump-super.c | 4 ++--
 ctree.h                   | 6 ++----
 2 files changed, 4 insertions(+), 6 deletions(-)
cmds-inspect-dump-super.c +0 -0
index e965267c5d96..3f33931ed9bc 100644
cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391
Quoted 7 lines
cmds-inspect-dump-super.c +2 -2
@@ -387,8 +387,8 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
 	       (unsigned long long)btrfs_super_chunk_root_level(sb));
 	printf("log_root\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root(sb));
-	printf("log_root_transid\t%llu\n",
-	       (unsigned long long)btrfs_super_log_root_transid(sb));
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.

Quoted 8 lines

Quoted 5 lines
It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.
But what is the point of having something which always shows 0 and is essentially unused?

Personally speaking, even it's in fact never used, it is still part of the specification of btrfs super blocks.

Even it's a bad decision we made a long time ago, we still need to mark it as unused, other than converting it back to "reserved".

To make it short and clear, if some member is specified in early specification, even it's never used, we still need to mark it unused and keep part of naming.

Thanks,
Qu

Quoted 35 lines

Thanks,
Qu

Quoted 29 lines

cmds-inspect-dump-super.c +0 -0

 	printf("log_root_level\t\t%llu\n",
 	       (unsigned long long)btrfs_super_log_root_level(sb));
 	printf("total_bytes\t\t%llu\n",

ctree.h +2 -4

index 4719962df67d..a314fdb102b0 100644
@@ -427,8 +427,8 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	/* This member is never touched, should always be 0 */
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;

@@ -2203,8 +2203,6 @@ BTRFS_SETGET_STACK_FUNCS(super_chunk_root_level, struct btrfs_super_block,
 			 chunk_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_log_root, struct btrfs_super_block,
 			 log_root, 64);
-BTRFS_SETGET_STACK_FUNCS(super_log_root_transid, struct btrfs_super_block,
-			 log_root_transid, 64);
 BTRFS_SETGET_STACK_FUNCS(super_log_root_level, struct btrfs_super_block,
 			 log_root_level, 8);
 BTRFS_SETGET_STACK_FUNCS(super_total_bytes, struct btrfs_super_block,

David Sterba

2018-10-24 14:30 UTC #6 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 17 lines · Qu Wenruo

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391
Quoted 2 lines
cmds-inspect-dump-super.c +2 -0
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.
Quoted 8 lines
Quoted 5 lines
It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.
But what is the point of having something which always shows 0 and is essentially unused?
Personally speaking, even it's in fact never used, it is still part of the specification of btrfs super blocks.

Quoted 6 lines

Even it's a bad decision we made a long time ago, we still need to mark it as unused, other than converting it back to "reserved".
To make it short and clear, if some member is specified in early specification, even it's never used, we still need to mark it unused and keep part of naming.

Agreed, follows the same patern as the leafsize. The superblock dump is a debugging and bug report tool, the full output is desirable.

Nikolay Borisov

2018-10-24 14:48 UTC #7 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 21 lines · David Sterba

Quoted 20 lines · Qu Wenruo
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
cmds-inspect-dump-super.c static void dump_superblock(struct btrfs_super_block *sb, int full) · line 391
Quoted 2 lines
cmds-inspect-dump-super.c +2 -0
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.
Quoted 8 lines
Quoted 5 lines
It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.
But what is the point of having something which always shows 0 and is essentially unused?
Personally speaking, even it's in fact never used, it is still part of the specification of btrfs super blocks.
Even it's a bad decision we made a long time ago, we still need to mark it as unused, other than converting it back to "reserved".

Quoted 6 lines

Quoted 3 lines
To make it short and clear, if some member is specified in early specification, even it's never used, we still need to mark it unused and keep part of naming.
Agreed, follows the same patern as the leafsize. The superblock dump is a debugging and bug report tool, the full output is desirable.

I really don't want to get into the argument but I think we should really name unused fields unusedX where X is some number. Looking at the code in struct btrfs_root_backup we have 2 unused fields. In the superblock we have unused space which is called 'reserved'. In struct btrfs_disk_balance_args there is a field called unused, same thing for struct btrfs_balance_item.

In btrfs_inode_item we have 'reserved' field, same thing for btrfs_root_item.

So the code base is yet again highly inconsistent and looking at it there is only a single field following the __unused_original_name, so it's really the exception rather than the rule.

Again, I would argue that once a field is deprecated or in this case it has _never_ actually been used then we might as well rename it to something cryptic so as not to attach (false) meaning to it. Just my 50 cents

David Sterba

2018-10-25 11:18 UTC #8 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 38 lines · Nikolay Borisov

Quoted 21 lines · David Sterba
Quoted 20 lines · Qu Wenruo
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2 -0
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.
Quoted 8 lines
Quoted 5 lines
It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.
But what is the point of having something which always shows 0 and is essentially unused?
Personally speaking, even it's in fact never used, it is still part of the specification of btrfs super blocks.
Even it's a bad decision we made a long time ago, we still need to mark it as unused, other than converting it back to "reserved".
Quoted 6 lines
Quoted 3 lines
To make it short and clear, if some member is specified in early specification, even it's never used, we still need to mark it unused and keep part of naming.
Agreed, follows the same patern as the leafsize. The superblock dump is a debugging and bug report tool, the full output is desirable.
I really don't want to get into the argument but I think we should really name unused fields unusedX where X is some number. Looking at the code in struct btrfs_root_backup we have 2 unused fields. In the superblock we have unused space which is called 'reserved'. In struct btrfs_disk_balance_args there is a field called unused, same thing for struct btrfs_balance_item.

Quoted 6 lines

In btrfs_inode_item we have 'reserved' field, same thing for btrfs_root_item.
So the code base is yet again highly inconsistent and looking at it there is only a single field following the __unused_original_name, so it's really the exception rather than the rule.

You're right about the inconsistent namig, for the "reserved for future use" members. This could be unified to "reserved", and even though it's in a public header I would not expect any application using the items.

The __unused_original_name is a different kind of "unused", as it became obsolete at some point and the bytes cannot be reused, unlike the reserved ones.

It's an exception because it was the first instance, there was no established rule/pattern to follow just a deliberate choice in the naming so it captures the original purpose and current status.

Quoted 4 lines

Again, I would argue that once a field is deprecated or in this case it has _never_ actually been used then we might as well rename it to something cryptic so as not to attach (false) meaning to it. Just my 50 cents

The log_root_transid is a again different from leafsize. I don't know what exactly you mean by the cryptic naming here, I'd rather keep the name selfexplanatory. Using 'reserved' could be misleading and somebody would want to use it for futher extensions.

Nikolay Borisov

2018-10-25 20:40 UTC #9 lore raw

Re: [PATCH 2/2] btrfs-progs: Deprecate unused super block member log_root_transid

Quoted 63 lines · David Sterba

Quoted 38 lines · Nikolay Borisov
Quoted 21 lines · David Sterba
Quoted 20 lines · Qu Wenruo
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Review
Quoted 2 lines
(quoted diff) +2 -0
+	printf("log_root_transid (deprecated)\t%llu\n",
+	       le64_to_cpu(sb->__unused_log_root_transid));
This should be entirely removed.
Quoted 8 lines
Quoted 5 lines
It looks OK to me.
Just like the old leafsize.
And if we try to use this member again, even old progs could show it without problem.
But what is the point of having something which always shows 0 and is essentially unused?
Personally speaking, even it's in fact never used, it is still part of the specification of btrfs super blocks.
Even it's a bad decision we made a long time ago, we still need to mark it as unused, other than converting it back to "reserved".
Quoted 6 lines
Quoted 3 lines
To make it short and clear, if some member is specified in early specification, even it's never used, we still need to mark it unused and keep part of naming.
Agreed, follows the same patern as the leafsize. The superblock dump is a debugging and bug report tool, the full output is desirable.
I really don't want to get into the argument but I think we should really name unused fields unusedX where X is some number. Looking at the code in struct btrfs_root_backup we have 2 unused fields. In the superblock we have unused space which is called 'reserved'. In struct btrfs_disk_balance_args there is a field called unused, same thing for struct btrfs_balance_item.
Quoted 6 lines
In btrfs_inode_item we have 'reserved' field, same thing for btrfs_root_item.
So the code base is yet again highly inconsistent and looking at it there is only a single field following the __unused_original_name, so it's really the exception rather than the rule.
You're right about the inconsistent namig, for the "reserved for future use" members. This could be unified to "reserved", and even though it's in a public header I would not expect any application using the items.
The __unused_original_name is a different kind of "unused", as it became obsolete at some point and the bytes cannot be reused, unlike the reserved ones.
It's an exception because it was the first instance, there was no established rule/pattern to follow just a deliberate choice in the naming so it captures the original purpose and current status.
Quoted 4 lines
Again, I would argue that once a field is deprecated or in this case it has _never_ actually been used then we might as well rename it to something cryptic so as not to attach (false) meaning to it. Just my 50 cents

Quoted 4 lines

The log_root_transid is a again different from leafsize. I don't know what exactly you mean by the cryptic naming here, I'd rather keep the name selfexplanatory. Using 'reserved' could be misleading and somebody would want to use it for futher extensions.

But this is exactly my point - log_root_transid can indeed be repurposed because it has _never_ been used in the code.