I was cleaning up a neighbors hard drive today by deleting a bunch of
windows-generated partitions - backups, etc., while removing a no longer
wanted XP installation then moving and re-sizing the Linux partitions. In
the process, I started to wonder about how this is handled on GPT drives
which know nada about extended partitions and such.
Specifically, if I remove say sda3 (out of sda1-9), are any other partition
numbers affected or do they retain their original sequence number? How about
creating a new partition in the vacated space - is it assigned the same
number as the deleted partition or is assigned a new number (10, in the
example?
I know that you can get some interesting results with fragmented partitions
on standard formatted disks, but how does GPT deal with such manipulation?
Suppose I have partitions “sda1” through “sda6”. I delete “sda3”, and then put two smaller partitions into that space.
I haven’t actually done that. But my experience suggests that the two new partitions will be “sda7” and “sda8”, and the disk will no longer have an “sda3”. However, “gdisk” does have a command that would renumber all of the partitions in sequence, if you prefer that.
When people upgraded from Windows 8 to Windows 8.1, the process split of a small partition from the main data partition. And Windows did renumber all of the partitions to keep them in sequence order of their position. There were a few posts on opensuse forums, of people with linux that would no longer boot because the root partition had the wrong partition number. That’s fixable, but causes some frustration.
I do not know what “fdisk”, “parted” or “gparted” do in this situation. I’m guessing that they are similar to “gdisk” and try to avoid causing problems for linux. Maybe somebody who has tried can comment.
Best advice: mount only with label or UUID of the file system, since those won’t change (until the partition is reformatted).
For manual mounts, this doesn’t much matter as long as you are taking notice. But once you automate a mount, it is best to do it in a way that won’t change.
I do notice that the opensuse installer remembers labels. So if you reformat the root partition for install, it will probably get the same label back. It won’t get the same UUID.
Grub2 (and grub2-efi) seems to use UUID. When running “grub2-mkconfig” it will generate a config that uses UUID to keep track of partitions. I’m not sure if there is a way to persuade it to use labels instead.
On 2014-12-05 13:46, nrickert wrote:
>
> whonea;2680848 Wrote:
>> …, but how does GPT deal with such manipulation?
> It doesn’t.
>
> Or, in more detail, it depends on the software.
Right.
It is actually the same thing as in traditional partitions.
The traditional partition has two structures. One is a real table with
fixed structures, similar to GPT now. Another is a linked list of entries.
If on the traditional table you removed a partition in the 1…4 group,
the numbers stayed. Renumbering means in fact moving the partition table
metadata from one slot in the table to another. This is the same in GPT,
you have to move the contents of the slots. Which is a somewhat
dangerous operation so it is not normally done (consider what happens if
the software crashes while shifting slots).
In the traditional table, the partitions from 5 onwards are a linked
list: each entry points to the next slot. If you delete one, say number
6, you have to make number 5 point to number 7, so all numbers shift
automatically.
Maybe partitioners could have an option to shift slots on request.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
> The traditional partition has two structures. One is a real table with
> fixed structures, similar to GPT now. Another is a linked list of entries.
Right, the Primary/Extended kludge which can be readily patched if you know
what you are doing.
> If on the traditional table you removed a partition in the 1…4 group,
> the numbers stayed. Renumbering means in fact moving the partition table
> metadata from one slot in the table to another. This is the same in GPT,
> you have to move the contents of the slots. Which is a somewhat
> dangerous operation so it is not normally done (consider what happens if
> the software crashes while shifting slots).
>
> In the traditional table, the partitions from 5 onwards are a linked
> list: each entry points to the next slot. If you delete one, say number
> 6, you have to make number 5 point to number 7, so all numbers shift
> automatically.
>
>
> Maybe partitioners could have an option to shift slots on request.
>
> The traditional partition has two structures. One is a real table with
> fixed structures, similar to GPT now. Another is a linked list of entries.
Right - the extended/primary kludge. At least these structures can be
patched if one knows what he is doing.
> If on the traditional table you removed a partition in the 1…4 group,
> the numbers stayed. Renumbering means in fact moving the partition table
> metadata from one slot in the table to another. This is the same in GPT,
> you have to move the contents of the slots. Which is a somewhat
> dangerous operation so it is not normally done (consider what happens if
> the software crashes while shifting slots).
>
> In the traditional table, the partitions from 5 onwards are a linked
> list: each entry points to the next slot. If you delete one, say number
> 6, you have to make number 5 point to number 7, so all numbers shift
> automatically.
Even harder to deal with is the case where a primary that comes before the
extended partitions is deleted then reallocated. All sorts of fun and games
to be played.
> Maybe partitioners could have an option to shift slots on request.
It appears that GPT, at least as implemented in the Linux versions I’ve
used, correctly handles new partitions which fill in open space created in
the middle of the disk by removing a partition. The only example I have
shows a case where the Win 8 system was created by some Win diagnostic and
is assumed the index number of the partition I had deleted to re-fill the
existing numerical list - no existing partitions were affected. That was a
wierd, odd sized partition that left a large gap. When I later installed a
test of 13.2, the installation created 2 new partitions with index values
that just used values higher than what existed since there was no missing
index. That’s the only GPT formatted disk I have so I’m not sure whether
using index values that may be missing from the current list or if that was
an artifact of of win vs. linux partitioners.
Probably the only way to be sure will be to take a spare drive, set it up
for GPT then play with the different scenarios. Sounds like a good project
to try before messing with a disk I am actively using!
On 2014-12-05 23:49, Will Honea wrote:
> Carlos E. R. wrote:
> Even harder to deal with is the case where a primary that comes before the
> extended partitions is deleted then reallocated. All sorts of fun and games
> to be played.
It is even possible to move a partition from primary to logical, or the
other way round. Very funny. Or rather not. I think I saw a tool that
did it, time ago. I don’t remember which.
> index. That’s the only GPT formatted disk I have so I’m not sure whether
> using index values that may be missing from the current list or if that was
> an artifact of of win vs. linux partitioners.
They are slots on a fixed size table, they can be used or not. The slots
are numbered, like flats in a building. You can not add new flats or
move them. You can move the furniture and the people, though. Not a very
good example… PO boxes?
It is up to the software to reuse an empty slot in the middle, or a
fresh one from the end of the table, or anywhere at all. As long the
contents do not overlap…
> Probably the only way to be sure will be to take a spare drive, set it up
> for GPT then play with the different scenarios. Sounds like a good project
> to try before messing with a disk I am actively using!
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
