btrfs-progs: print-tree: Enehance uuid item print
PATCH v2 1/1 btrfs-progs: print-tree: Enehance uuid item print
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the key objectid and key offset is just half of the UUID.
However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format.
Although true engineer can easily handle it by convert it in their brain, but to make it easier for search, output the result UUID using the 36 chars format.
---
Inspired by UUID related work from Misono-san.
v2:
Use explicit btrfs_key_to_uuid() function to do the convert, and add more comment why we should do that. Suggested by Nikolay.
--- print-tree.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)
print-tree.c +31 -3
@@ -803,14 +803,42 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key) } } -static void print_uuid_item (struct extent_buffer *l,unsigned long offset, -u32 item_size) +static void btrfs_key_to_uuid (struct btrfs_key *key,u8 *uuid) { +/* +* UUID we use is in byte order, which means: +* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +* UUID:0x 12 34 56-78 90-ab cd-ef 12-34 56 78 90 ab cd ef +* +* And we store them as is in btrfs_*disk*_key: +* +* Low bit High bit|Low bit High bit +* LE64:0x 12 34 56-78 90-ab cd-ef|12-34 56 78 90 ab cd ef +* key.objectid | key.offset +* +* So here we just need to convert from native endian to LE to +* get the byte order UUID. +*/ +put_unaligned_le64 (key->objectid, uuid); +put_unaligned_le64 (key->offset, uuid +sizeof (u64)); +} + +static void print_uuid_item (struct extent_buffer *l,int slot, +unsigned long offset,u32 item_size) +{ +struct btrfs_key key; +char uuid_str[BTRFS_UUID_UNPARSED_SIZE ]; +u8 uuid[BTRFS_UUID_SIZE ]; + +btrfs_item_key_to_cpu (l, &key, slot); +btrfs_key_to_uuid (&key, uuid); +uuid_unparse (uuid, uuid_str);if (item_size & (sizeof (u64) -1 )) {printf ("btrfs: uuid item with illegal size %lu!\n" , (unsigned long )item_size);return ; } +printf ("\t\tuuid %s\n" , uuid_str);while (item_size) {__le64 subvol_id;
@@ -1297,7 +1325,7 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)break ;case BTRFS_UUID_KEY_SUBVOL :case BTRFS_UUID_KEY_RECEIVED_SUBVOL : -print_uuid_item (eb,btrfs_item_ptr_offset (eb, i), +print_uuid_item (eb, i,btrfs_item_ptr_offset (eb, i),btrfs_item_size_nr (eb, i));break ;case BTRFS_STRING_ITEM_KEY : {
Signature · 1 line
2.14.3
Quoted 26 lines · Qu Wenruo
For key type
BTRFS_UUID_KEY_SUBVOLorBTRFS_UUID_KEY_RECEIVED_SUBVOLthe key objectid and key offset is just half of the UUID.However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format.
Although true engineer can easily handle it by convert it in their brain, but to make it easier for search, output the result UUID using the 36 chars format.
Signed-off-by Qu Wenruo <[email protected]>---
Inspired by UUID related work from Misono-san.
v2:
Use explicitbtrfs_key_to_uuid()function to do the convert, and add more comment why we should do that. Suggested by Nikolay.--- print-tree.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)print-tree.c +0
-0
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 809
Quoted 9 lines
print-tree.c +3
-2@@ -803,14 +803,42 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key) } } -static void print_uuid_item (struct extent_buffer *l,unsigned long offset, -u32 item_size) +static void btrfs_key_to_uuid (struct btrfs_key *key,u8 *uuid) { +/* +* UUID we use is in byte order, which means:
"byte order" term per-se doesn't really say anything about how bytes are stored, we either have little endian or big endian. So this sentence needs to be more explicit "BTRFS always represents uuid in little endian"
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 813
Quoted 4 lines
print-tree.c +4
-0+* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +* UUID:0x 12 34 56-78 90-ab cd-ef 12-34 56 78 90 ab cd ef +* +* And we store them as is in btrfs_*disk*_key:
This could be "BTRFS' on-disk format also uses little-endian so the in-memory uuid is stored on-disk without any change to endiannes"
Quoted 41 lines
print-tree.c +24
-1+* +* Low bit High bit|Low bit High bit +* LE64:0x 12 34 56-78 90-ab cd-ef|12-34 56 78 90 ab cd ef +* key.objectid | key.offset +* +* So here we just need to convert from native endian to LE to +* get the byte order UUID. +*/ +put_unaligned_le64 (key->objectid, uuid); +put_unaligned_le64 (key->offset, uuid +sizeof (u64)); +} + +static void print_uuid_item (struct extent_buffer *l,int slot, +unsigned long offset,u32 item_size) +{ +struct btrfs_key key; +char uuid_str[BTRFS_UUID_UNPARSED_SIZE ]; +u8 uuid[BTRFS_UUID_SIZE ]; + +btrfs_item_key_to_cpu (l, &key, slot); +btrfs_key_to_uuid (&key, uuid); +uuid_unparse (uuid, uuid_str);if (item_size & (sizeof (u64) -1 )) {printf ("btrfs: uuid item with illegal size %lu!\n" , (unsigned long )item_size);return ; } +printf ("\t\tuuid %s\n" , uuid_str);while (item_size) {__le64 subvol_id;@@ -1297,7 +1325,7 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)break ;case BTRFS_UUID_KEY_SUBVOL :case BTRFS_UUID_KEY_RECEIVED_SUBVOL : -print_uuid_item (eb,btrfs_item_ptr_offset (eb, i), +print_uuid_item (eb, i,btrfs_item_ptr_offset (eb, i),btrfs_item_size_nr (eb, i));break ;case BTRFS_STRING_ITEM_KEY : {
Quoted 32 lines · Nikolay Borisov
Quoted 29 lines · Qu Wenruo
For key type
BTRFS_UUID_KEY_SUBVOLorBTRFS_UUID_KEY_RECEIVED_SUBVOLthe key objectid and key offset is just half of the UUID.However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format.
Although true engineer can easily handle it by convert it in their brain, but to make it easier for search, output the result UUID using the 36 chars format.
Signed-off-by Qu Wenruo <[email protected]>---
Inspired by UUID related work from Misono-san.
v2:
Use explicitbtrfs_key_to_uuid()function to do the convert, and add more comment why we should do that. Suggested by Nikolay.--- print-tree.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)print-tree.c +0
-0@@ -803,14 +803,42 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key) } }
Quoted 9 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 809
Quoted 6 lines
print-tree.c +3
-2-static void print_uuid_item (struct extent_buffer *l,unsigned long offset, -u32 item_size) +static void btrfs_key_to_uuid (struct btrfs_key *key,u8 *uuid) { +/* +* UUID we use is in byte order, which means: "byte order" term per-se doesn't really say anything about how bytes are stored, we either have little endian or big endian. So this sentence needs to be more explicit "BTRFS always represents uuid in little endian"
Well, it turned out that I get confused with the term "byte order" and "network order", and in this case I mean "network order" which is also BE.
And just in case, if you're referring the UUID as u128, then it's definitely big endian.
Quoted 7 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 813
Quoted 5 lines
print-tree.c +4
-0+* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +* UUID:0x 12 34 56-78 90-ab cd-ef 12-34 56 78 90 ab cd ef +* +* And we store them as is in btrfs_*disk*_key: This could be "BTRFS' on-disk format also uses little-endian so the in-memory uuid is stored on-disk without any change to endiannes"
While I'm always confused by your mention of endian in this case.
Here UUID is just 16 bytes, why endian is envolved? (We're not talking about true UUID)
Isn't endian only affecting structure over 1 byte?
Here is just a stream of bytes, why endian is affected in UUID? We didn't even trust uuid as u128 at all.
To me, only when we access things like key->objectid/offset we cares about endian. For key->type and CSUM, there is no endian at all as we are just accessing bytes. (Unless we convert them into u32/u64/u128)
Thanks,
Qu
Quoted 48 lines
Quoted 35 lines
print-tree.c +23
-0+* +* Low bit High bit|Low bit High bit +* LE64:0x 12 34 56-78 90-ab cd-ef|12-34 56 78 90 ab cd ef +* key.objectid | key.offset +* +* So here we just need to convert from native endian to LE to +* get the byte order UUID. +*/ +put_unaligned_le64 (key->objectid, uuid); +put_unaligned_le64 (key->offset, uuid +sizeof (u64)); +} + +static void print_uuid_item (struct extent_buffer *l,int slot, +unsigned long offset,u32 item_size) +{ +struct btrfs_key key; +char uuid_str[BTRFS_UUID_UNPARSED_SIZE ]; +u8 uuid[BTRFS_UUID_SIZE ]; + +btrfs_item_key_to_cpu (l, &key, slot); +btrfs_key_to_uuid (&key, uuid); +uuid_unparse (uuid, uuid_str);if (item_size & (sizeof (u64) -1 )) {printf ("btrfs: uuid item with illegal size %lu!\n" , (unsigned long )item_size);return ; } +printf ("\t\tuuid %s\n" , uuid_str);while (item_size) {__le64 subvol_id;print-tree.c void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb) · line 1331
Quoted 8 lines
print-tree.c +1
-1@@ -1297,7 +1325,7 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)break ;case BTRFS_UUID_KEY_SUBVOL :case BTRFS_UUID_KEY_RECEIVED_SUBVOL : -print_uuid_item (eb,btrfs_item_ptr_offset (eb, i), +print_uuid_item (eb, i,btrfs_item_ptr_offset (eb, i),btrfs_item_size_nr (eb, i));break ;case BTRFS_STRING_ITEM_KEY : {--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 65 lines · Qu Wenruo
Quoted 32 lines · Nikolay Borisov
Quoted 29 lines · Qu Wenruo
For key type
BTRFS_UUID_KEY_SUBVOLorBTRFS_UUID_KEY_RECEIVED_SUBVOLthe key objectid and key offset is just half of the UUID.However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format.
Although true engineer can easily handle it by convert it in their brain, but to make it easier for search, output the result UUID using the 36 chars format.
Signed-off-by Qu Wenruo <[email protected]>---
Inspired by UUID related work from Misono-san.
v2:
Use explicitbtrfs_key_to_uuid()function to do the convert, and add more comment why we should do that. Suggested by Nikolay.--- print-tree.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)print-tree.c +0
-0@@ -803,14 +803,42 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key) } }Quoted 9 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 809
Quoted 6 lines
print-tree.c +3
-2-static void print_uuid_item (struct extent_buffer *l,unsigned long offset, -u32 item_size) +static void btrfs_key_to_uuid (struct btrfs_key *key,u8 *uuid) { +/* +* UUID we use is in byte order, which means: "byte order" term per-se doesn't really say anything about how bytes are stored, we either have little endian or big endian. So this sentence needs to be more explicit "BTRFS always represents uuid in little endian"
Well, it turned out that I get confused with the term "byte order" and "network order", and in this case I mean "network order" which is also BE.
And just in case, if you're referring the UUID as u128, then it's definitely big endian.
Quoted 7 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 813
Quoted 5 lines
print-tree.c +4
-0+* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +* UUID:0x 12 34 56-78 90-ab cd-ef 12-34 56 78 90 ab cd ef +* +* And we store them as is in btrfs_*disk*_key: This could be "BTRFS' on-disk format also uses little-endian so the in-memory uuid is stored on-disk without any change to endiannes"
While I'm always confused by your mention of endian in this case.
Here UUID is just 16 bytes, why endian is envolved? (We're not talking about true UUID)
Isn't endian only affecting structure over 1 byte?
Quoted 6 lines
Here is just a stream of bytes, why endian is affected in UUID? We didn't even trust uuid as u128 at all.
To me, only when we access things like key->objectid/offset we cares about endian. For
key->typeand CSUM, there is no endian at all as we are just accessing bytes. (Unless we convert them into u32/u64/u128)
I don't understand where your confusion arises from but here is how I understand things.
Btrfs generates uids by invoking uuid_le_gen (which actually calls guid_gen). guid_gen in turn generates a 128 bit LE value, consisting of 16 bytes. Then in order to add this uuid to the uuid tree we actually split those 16 bytes into 2 u64 values by calling btrfs_uuid_to_key and assigne them to the objectid/offset members of the btrfs key. At this point the endiannes of each of these 2 values is important since they are being treated as u64.
So actually order is important and btrfs chose to work with LE values explicitly so what I'm asking is to document this fact explicitly in the code handling this otherwise one has to go and dig around the code to figure out why you are doing an on-disk (LE) -> host cpu(could be LE or BE) -> LE conversion.
I hope this makes things clear
Quoted 53 lines
Thanks,
QuQuoted 48 lines
Quoted 35 lines
print-tree.c +23
-0+* +* Low bit High bit|Low bit High bit +* LE64:0x 12 34 56-78 90-ab cd-ef|12-34 56 78 90 ab cd ef +* key.objectid | key.offset +* +* So here we just need to convert from native endian to LE to +* get the byte order UUID. +*/ +put_unaligned_le64 (key->objectid, uuid); +put_unaligned_le64 (key->offset, uuid +sizeof (u64)); +} + +static void print_uuid_item (struct extent_buffer *l,int slot, +unsigned long offset,u32 item_size) +{ +struct btrfs_key key; +char uuid_str[BTRFS_UUID_UNPARSED_SIZE ]; +u8 uuid[BTRFS_UUID_SIZE ]; + +btrfs_item_key_to_cpu (l, &key, slot); +btrfs_key_to_uuid (&key, uuid); +uuid_unparse (uuid, uuid_str);if (item_size & (sizeof (u64) -1 )) {printf ("btrfs: uuid item with illegal size %lu!\n" , (unsigned long )item_size);return ; } +printf ("\t\tuuid %s\n" , uuid_str);while (item_size) {__le64 subvol_id;print-tree.c void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb) · line 1331
Quoted 8 lines
print-tree.c +1
-1@@ -1297,7 +1325,7 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)break ;case BTRFS_UUID_KEY_SUBVOL :case BTRFS_UUID_KEY_RECEIVED_SUBVOL : -print_uuid_item (eb,btrfs_item_ptr_offset (eb, i), +print_uuid_item (eb, i,btrfs_item_ptr_offset (eb, i),btrfs_item_size_nr (eb, i));break ;case BTRFS_STRING_ITEM_KEY : {--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 75 lines · Nikolay Borisov
Quoted 65 lines · Qu Wenruo
Quoted 32 lines · Nikolay Borisov
Quoted 29 lines · Qu Wenruo
For key type
BTRFS_UUID_KEY_SUBVOLorBTRFS_UUID_KEY_RECEIVED_SUBVOLthe key objectid and key offset is just half of the UUID.However we just print the key as %llu, which is converted from little endian, not byte order for UUID, nor the traditional 36 bytes human readable uuid format.
Although true engineer can easily handle it by convert it in their brain, but to make it easier for search, output the result UUID using the 36 chars format.
Signed-off-by Qu Wenruo <[email protected]>---
Inspired by UUID related work from Misono-san.
v2:
Use explicitbtrfs_key_to_uuid()function to do the convert, and add more comment why we should do that. Suggested by Nikolay.--- print-tree.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-)print-tree.c +0
-0@@ -803,14 +803,42 @@ void btrfs_print_key(struct btrfs_disk_key *disk_key) } }Quoted 9 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 809
Quoted 6 lines
print-tree.c +3
-2-static void print_uuid_item (struct extent_buffer *l,unsigned long offset, -u32 item_size) +static void btrfs_key_to_uuid (struct btrfs_key *key,u8 *uuid) { +/* +* UUID we use is in byte order, which means: "byte order" term per-se doesn't really say anything about how bytes are stored, we either have little endian or big endian. So this sentence needs to be more explicit "BTRFS always represents uuid in little endian"
Well, it turned out that I get confused with the term "byte order" and "network order", and in this case I mean "network order" which is also BE.
And just in case, if you're referring the UUID as u128, then it's definitely big endian.
Quoted 7 lines
print-tree.c void btrfs_print_key(struct btrfs_disk_key *disk_key) · line 813
Quoted 5 lines
print-tree.c +4
-0+* 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +* UUID:0x 12 34 56-78 90-ab cd-ef 12-34 56 78 90 ab cd ef +* +* And we store them as is in btrfs_*disk*_key: This could be "BTRFS' on-disk format also uses little-endian so the in-memory uuid is stored on-disk without any change to endiannes"
While I'm always confused by your mention of endian in this case.
Here UUID is just 16 bytes, why endian is envolved? (We're not talking about true UUID)
Isn't endian only affecting structure over 1 byte?Quoted 6 lines
Here is just a stream of bytes, why endian is affected in UUID? We didn't even trust uuid as u128 at all.
To me, only when we access things like key->objectid/offset we cares about endian. For
key->typeand CSUM, there is no endian at all as we are just accessing bytes. (Unless we convert them into u32/u64/u128)
Quoted 6 lines
I don't understand where your confusion arises from but here is how I understand things.
Btrfs generates uids by invoking
uuid_le_gen(which actually callsguid_gen).guid_genin turn generates a 128 bit LE value, consisting of 16 bytes.
Here, just 16 bytes, an array of bytes, no endian involved at all.
Quoted 3 lines
Then in order to add this uuid to the uuid tree we actually split those 16 bytes into 2 u64 values by calling
btrfs_uuid_to_keyand assigne them to the objectid/offset members of the btrfs key.
Only at this specially timing we need to care about endian.
Because we are converting an array to u32, which is larger than one byte, we need to consider endian.
And what we do is, forcing the 8 bytes array to be treated as u64 native endian. And then convert native endian u64 to LE64.
The only endian like problem I can think of here is, which (object/offset) represents the leading half (offset +0).
Quoted 3 lines
At this
point the endiannes of each of these 2 values is important since they are being treated as u64.
If kernel code is changed to things like:
---memcpy(&disk_key.objectid, uuid , 8);memcpy(&disk_key.offset, uuid + 8, 8);
---
Maybe it's easier for both us to understand each other.
Quoted 6 lines
So actually order is important and btrfs chose to work with LE values explicitly so what I'm asking is to document this fact explicitly in the code handling this otherwise one has to go and dig around the code to figure out why you are doing an on-disk (LE) -> host cpu(could be LE or BE) -> LE conversion.
But since UUID is just an array of bytes, what ever the endian btrfs choose doesn't affect the UUID at all.
Even we choose on-disk BE, it doesn't matter at all. We only needs to get an array of bytes.
Just like what we treat the uuid in root_item, just memcpy()/write_extent_buffer(), no one really cares about endian at all, since it's just an array of bytes, not affected at all.
So here my point is, there is no endian for BTRFS uuid.
And in fact CPU native endian is not even involved at all. We only need to recover an array of bytes, and no matter what endian we're using, we will get the same array of bytes, both in memory and on disk.
Just like what we did by calling memcpy()/write_extent_buffer()/read_extent_buffer() and without even thinking about endian.
That's also why I want to get rid of the put_unaligned_u64() and just put a memcpy().
Thanks,
Qu
Quoted 63 lines
I hope this makes things clear
Quoted 53 lines
Thanks,
QuQuoted 48 lines
Quoted 35 lines
print-tree.c +23
-0+* +* Low bit High bit|Low bit High bit +* LE64:0x 12 34 56-78 90-ab cd-ef|12-34 56 78 90 ab cd ef +* key.objectid | key.offset +* +* So here we just need to convert from native endian to LE to +* get the byte order UUID. +*/ +put_unaligned_le64 (key->objectid, uuid); +put_unaligned_le64 (key->offset, uuid +sizeof (u64)); +} + +static void print_uuid_item (struct extent_buffer *l,int slot, +unsigned long offset,u32 item_size) +{ +struct btrfs_key key; +char uuid_str[BTRFS_UUID_UNPARSED_SIZE ]; +u8 uuid[BTRFS_UUID_SIZE ]; + +btrfs_item_key_to_cpu (l, &key, slot); +btrfs_key_to_uuid (&key, uuid); +uuid_unparse (uuid, uuid_str);if (item_size & (sizeof (u64) -1 )) {printf ("btrfs: uuid item with illegal size %lu!\n" , (unsigned long )item_size);return ; } +printf ("\t\tuuid %s\n" , uuid_str);while (item_size) {__le64 subvol_id;print-tree.c void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb) · line 1331
Quoted 8 lines
print-tree.c +1
-1@@ -1297,7 +1325,7 @@ void btrfs_print_leaf(struct btrfs_root *root, struct extent_buffer *eb)break ;case BTRFS_UUID_KEY_SUBVOL :case BTRFS_UUID_KEY_RECEIVED_SUBVOL : -print_uuid_item (eb,btrfs_item_ptr_offset (eb, i), +print_uuid_item (eb, i,btrfs_item_ptr_offset (eb, i),btrfs_item_size_nr (eb, i));break ;case BTRFS_STRING_ITEM_KEY : {--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html