Skip to contentSkip to conversation

btrfs: Deprecate unused super block member, log_root_transid

PATCH In review Qu Wenruo 3 participants 3 messages Oct 12, 2018 Btrfs file system

lore
Share & tools
lore

Qu Wenruo

author
#0 lore raw

PATCH v2 1/1 btrfs: Deprecate unused super block member, log_root_transid

The member log_root_transid is never used.
It's always kept untouched even when updating log tree root.

And populating it without introducing new incompat flags could easily cause back-compatibility problems.
So just mark it unused.

---
changelog:
v2:
Remove the redundant comment.

---
 fs/btrfs/ctree.h | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
fs/btrfs/ctree.h +1 -4
index 53af9f5253f4..7adf5f4dcda4 100644
@@ -214,8 +214,7 @@ 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;
+	__le64 __unused_log_root_transid;
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;
@@ -2317,8 +2316,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
#1 lore raw
Quoted 21 lines · Qu Wenruo

The member log_root_transid is never used.
It's always kept untouched even when updating log tree root.

And populating it without introducing new incompat flags could easily cause back-compatibility problems.
So just mark it unused.

---
changelog:
v2:
Remove the redundant comment.

---
 fs/btrfs/ctree.h | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
fs/btrfs/ctree.h +0 -0
index 53af9f5253f4..7adf5f4dcda4 100644

fs/btrfs/ctree.h struct btrfs_super_block { · line 217

Quoted 6 lines
fs/btrfs/ctree.h +1 -2
@@ -214,8 +214,7 @@ 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;
+	__le64 __unused_log_root_transid;

why do you keep insisting on having "log_root_transid" in the name of this member? It was never used on-disk so for all intents and purposes log_root_transid doesn't mean anything? No need to resend, I'm sure David will change it on commit, nut I'm just curious.

Quoted 13 lines
fs/btrfs/ctree.h +0 -2
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;
@@ -2317,8 +2316,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,
#2 lore raw
Quoted 27 lines · Nikolay Borisov
Quoted 24 lines · Qu Wenruo

The member log_root_transid is never used.
It's always kept untouched even when updating log tree root.

And populating it without introducing new incompat flags could easily cause back-compatibility problems.
So just mark it unused.

---
changelog:
v2:
Remove the redundant comment.

---
 fs/btrfs/ctree.h | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
fs/btrfs/ctree.h +0 -0
index 53af9f5253f4..7adf5f4dcda4 100644
@@ -214,8 +214,7 @@ struct btrfs_super_block {
 	__le64 chunk_root;
 	__le64 log_root;
 
Quoted 8 lines

fs/btrfs/ctree.h struct btrfs_super_block { · line 217

Quoted 3 lines
fs/btrfs/ctree.h +1 -2
-	/* this will help find the new super based on the log root */
-	__le64 log_root_transid;
+	__le64 __unused_log_root_transid;

why do you keep insisting on having "log_root_transid" in the name of this member? It was never used on-disk so for all intents and purposes log_root_transid doesn't mean anything? No need to resend, I'm sure David will change it on commit, nut I'm just curious.

We have a similar case, leaf_size.
Although it differs from this case and it's still used, I prefer to have something showing that we at least planned to use this member.

Just in case one day we tries to use it again.

Thanks,
Qu

Quoted 15 lines
Quoted 15 lines
fs/btrfs/ctree.h +0 -2
 	__le64 total_bytes;
 	__le64 bytes_used;
 	__le64 root_dir_objectid;
@@ -2317,8 +2316,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,