* [PATCH] btrfs: Deprecate unused super block member, log_root_transid
@ 2018-10-12 6:26 Qu Wenruo
2018-10-12 6:31 ` Nikolay Borisov
0 siblings, 1 reply; 3+ messages in thread
From: Qu Wenruo @ 2018-10-12 6:26 UTC (permalink / raw)
To: linux-btrfs
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.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/btrfs/ctree.h | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 53af9f5253f4..9adc53db679a 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -214,8 +214,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;
@@ -2317,8 +2317,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.19.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: Deprecate unused super block member, log_root_transid
2018-10-12 6:26 [PATCH] btrfs: Deprecate unused super block member, log_root_transid Qu Wenruo
@ 2018-10-12 6:31 ` Nikolay Borisov
2018-10-12 6:32 ` Qu Wenruo
0 siblings, 1 reply; 3+ messages in thread
From: Nikolay Borisov @ 2018-10-12 6:31 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs
On 12.10.2018 09:26, Qu Wenruo wrote:
> 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.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> fs/btrfs/ctree.h | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 53af9f5253f4..9adc53db679a 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -214,8 +214,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;
no need to be that descriptive, that's the whole idea of switching the
parameter's name. Just use "reserved1" or "unused" or "padding", also
the name is eloquent enough that the comment is redundant.
> __le64 total_bytes;
> __le64 bytes_used;
> __le64 root_dir_objectid;
> @@ -2317,8 +2317,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,
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: Deprecate unused super block member, log_root_transid
2018-10-12 6:31 ` Nikolay Borisov
@ 2018-10-12 6:32 ` Qu Wenruo
0 siblings, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2018-10-12 6:32 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs
On 2018/10/12 下午2:31, Nikolay Borisov wrote:
>
>
> On 12.10.2018 09:26, Qu Wenruo wrote:
>> 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.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>> fs/btrfs/ctree.h | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index 53af9f5253f4..9adc53db679a 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -214,8 +214,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;
>
> no need to be that descriptive, that's the whole idea of switching the
> parameter's name. Just use "reserved1" or "unused" or "padding", also
> the name is eloquent enough that the comment is redundant.
Indeed, that comment will be gone.
Thanks,
Qu
>
>> __le64 total_bytes;
>> __le64 bytes_used;
>> __le64 root_dir_objectid;
>> @@ -2317,8 +2317,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,
>>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-12 6:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-12 6:26 [PATCH] btrfs: Deprecate unused super block member, log_root_transid Qu Wenruo
2018-10-12 6:31 ` Nikolay Borisov
2018-10-12 6:32 ` Qu Wenruo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).