Other why gpart restore not create same result as source geom?

B

bendany

Hello, I am using FreeBSD 14.0R
Code: 
root@vmhost:~ # uname -a
FreeBSD vmhost 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
I try to attach a same ssd to zroot zpool
while using the gpart restore, I cannot get extract same result.
Code: 
root@vmhost:~ # gpart show ada0
=>        40  1875384928  ada0  GPT  (894G)
          40      532480     1  efi  (260M)
      532520    67108864     2  freebsd-swap  (32G)
    67641384  1807743584     3  freebsd-zfs  (862G)

root@vmhost:~ # gpart backup ada0 | gpart restore -F ada1
root@vmhost:~ # gpart show ada1
=>        34  1875384941  ada1  GPT  (894G)
          34           6        - free -  (3.0K)
          40      532480     1  efi  (260M)
      532520    67108864     2  freebsd-swap  (32G)
    67641384  1807743584     3  freebsd-zfs  (862G)
  1875384968           7        - free -  (3.5K)
Why there are two free space at first and last partition?
if I manualy create gpt schema, it is fine.
Code: 
root@vmhost:~ # gpart destroy -F ada1
ada1 destroyed
root@vmhost:~ # gpart create -s gpt ada1
ada1 created
root@vmhost:~ # gpart add -t efi -l efiboot0 -s 532480 ada1
ada1p1 added
root@vmhost:~ # gpart add -t freebsd-swap -s 67108864 ada1
ada1p2 added
root@vmhost:~ # gpart add -t freebsd-zfs ada1
ada1p3 added
root@vmhost:~ # gpart show ada1
=>        40  1875384928  ada1  GPT  (894G)
          40      532480     1  efi  (260M)
      532520    67108864     2  freebsd-swap  (32G)
    67641384  1807743584     3  freebsd-zfs  (862G)
I check gpart restore, there no more other options I can try
 
The starting block and size in blocks values for the partition are the same.
I think restore is just writing the value read by gctl_ro_param().
/usr/src/lib/geom/part/geom_part.c
 
Yes, I see the three partitions are all at the same values, and after sync data, it also can boot without any problem.
I just cannot understand why gpart list shows different result. need to dig the source.
 
So the source geom, was likely created with a "-a" to align partitions to 4k boundaries.
When you do the backup command it's reading where everything starts and ends, which are aligned.
Doing the restore to the different device, you are getting partitions created at the 4k boundaries, just like the start and end values.
If you are talking about the two extra "free" things, that's likely what is created and held internally by the data structures.
ada1 is even showing correct partition numbers so ada1 matches ada0.

I agree that it looks untidy, but if one understands what is going on, I consider it a minor nit that only would bother me before morning coffee.

But that's my opinion. I recognize that other's may have less tolerance for things like this than me.
 
The root cause is that default creation of gpt scheme is 4K align, while gpart restore has no switch to force whether 512 or 4k.
add a switch to gpart restore will solve this situation.
 
I don't see why a switch is needed.
You create partitions using gpart, at whatever alignment value you want.
That creates data structures on the disk representing start, end, labels or whatever else is needed.
gpart backup reads those datastructures and dumps them to stdout.
gpart restore takes that format and applies them to a device.
The restored device has partitions at the alignment and size of the original.
Adding an alignment switch on the restore I don't think helps with anything other than what in my opinion is a cosmetic thing in the output showing the freespace that is created by the original alignment.
 
mer said:
The restored device has partitions at the alignment and size of the original.
Click to expand...
The partitions are aligned, that's indeed not the problem. But the partition table itself is shifted 6 blocks.

Maybe the problem can be kind of circumvented? gpart create -s gpt ada1 (this should create the partition table starting at 40 instead of 34), then restore the saved table? gpart restore ada1 < backup.table.
 
Let's find out what happens. Here is an example: I have two identical SSDs, nda0 and nda1. I perform the following operations:
Code: 
root@vmhost:~ # gpart create -s gpt nda0
nda0 created
root@vmhost:~ # gpart add -t freebsd-zfs nda0
nda0p1 added
root@vmhost:~ # gpart show nda0
=>        40  3125627488  nda0  GPT  (1.5T)
          40  3125627488     1  freebsd-zfs  (1.5T)

root@vmhost:~ # gpart backup nda0 | gpart restore nda1
root@vmhost:~ # gpart show nda1
=>        34  3125627501  nda1  GPT  (1.5T)
          34           6        - free -  (3.0K)
          40  3125627488     1  freebsd-zfs  (1.5T)
  3125627528           7        - free -  (3.5K)
You can observe that there is free space at the beginning and at the end. This occurs because when I manually create the GPT schema, it defaults to 4k alignment.
During the gpart restore, it does not have this default or a switch to force 4k alignment.
If I dump nda0 and nda1 and compare them:
Code: 
root@vmhost:~ # gpart list nda0 > nda0.txt
root@vmhost:~ # gpart list nda1 > nda1.txt
root@vmhost:~ # diff nda0.txt nda1.txt
1c1
< Geom name: nda0
---
> Geom name: nda1
6,7c6,7
< last: 3125627527
< first: 40
---
> last: 3125627534
> first: 34
11c11
< 1. Name: nda0p1
---
> 1. Name: nda1p1
17,18c17,18
<    efimedia: HD(1,GPT,b36adcfe-ac71-11ee-b017-1c1b0d86a2ab,0x28,0xba4d4a60)
<    rawuuid: b36adcfe-ac71-11ee-b017-1c1b0d86a2ab
---
>    efimedia: HD(1,GPT,bc2a6a48-ac71-11ee-b017-1c1b0d86a2ab,0x28,0xba4d4a60)
>    rawuuid: bc2a6a48-ac71-11ee-b017-1c1b0d86a2ab
28c28
< 1. Name: nda0
---
> 1. Name: nda1
The main difference is in the first and last values. When not 4k aligned, the start and last values are not 4k-aligned, which is why there are two instances of free space.

As far as I know, there is no way to modify these two values after creation.

If I want two identical formats, we have to instruct gpart restore to force 4k alignment when creating the GPT schema, just like the behavior of
create -s gpt
 
SirDice said:
Maybe the problem can be kind of circumvented? gpart create -s gpt ada1 (this should create the partition table starting at 40 instead of 34), then restore the saved table? gpart restore ada1 < backup.table.
Click to expand...
There is no way can do that if there is a gpt schema exists.
Code: 
root@vmhost:~ # gpart create -s gpt nda1
nda1 created
root@vmhost:~ # gpart backup nda0 | gpart restore nda1
gpart: geom 'nda1': File exists
root@vmhost:~ #
 
bendany said:
There is no way can do that if there is a gpt schema exists.
Click to expand...
Oh, right. Bugger.

It's not going to matter though, it might look a little odd but the partitions themselves are properly lined up. And that's the only important factor.
 
You must log in or register to reply here.
Back
Top