Bug 250609 - gpart resize: bug in combined -a -s usage
Summary: gpart resize: bug in combined -a -s usage
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Robert Wing
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-25 20:14 UTC by Bernd Roth
Modified: 2024-01-20 22:26 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Roth 2020-10-25 20:14:02 UTC
12.1-RELEASE-p10
:~ # uname -a
FreeBSD <server> 12.1-RELEASE-p10 FreeBSD 12.1-RELEASE-p10 GENERIC  amd64

At first it seemed to be a bug in the -s switch.
Later i found it's the use of -a together with -s.

man gpart:
   resize        Resize a partition from geom geom and further identified by
                   the -i index option.  If the new size is not specified it
                   is automatically calculated to be the maximum available
                   from geom.

                   The resize command accepts these options:

                   -a alignment  If specified, then gpart utility tries to
                                 align partition size to be a multiple of the
                                 alignment value.
                  [-f ...]

                   -i index      Specifies the index of the partition to be
                                 resized.

                   -s size       Specifies the new size of the partition, in
                                 logical blocks.  A SI unit suffix is allowed.

:~ # gpart show -l ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40  2621440000     1  DLEFT2  (1.2T)
  2621440040  2516582400        - free -  (1.2T)
  5138022440  1258291200     3  (null)  (600G)
  6396313640   629145600     4  (null)  (300G)
  7025459240   788577888        - free -  (376G)

Inital condition: p1 is part of zpool raidz1. The pool should grow to ~2T. p3 and p4 are ufs placeholders to demonstrate the bug.



:~ # gpart resize -a 4k -i 1 -s 2691000000 ada5
ada5p1 resized

:~ # gpart show -l ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40  5138022400     1  DLEFT2  (2.4T)
  5138022440  1258291200     3  (null)  (600G)
  6396313640   629145600     4  (null)  (300G)
  7025459240   788577888        - free -  (376G)

It started when i noticed that the -s SIZE was ignored and all following free space was used.



:~ # gpart resize -a 4k -i 1 -s 2691000000 ada5
gpart: Device busy

This may be normal, the partition 1 is part of the active but unmounted pool.



:~ # gpart delete -i 3 ada5
ada5p3 deleted

:~ # gpart show -l ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40  5138022400     1  DLEFT2  (2.4T)
  5138022440  1258291200        - free -  (600G)
  6396313640   629145600     4  (null)  (300G)
  7025459240   788577888        - free -  (376G)

:~ # gpart resize -a 4k -i 1 -s 2.5T ada5
gpart: Invalid size param: Invalid argument

(Side topic: gpart doesn't understand it's own size format.)
(Personally i try to talk back to software like it talks to me. ;-) )

:~ # gpart resize -a 4k -i 1 -s 2600G ada5
ada5p1 resized

:~ # gpart show -l ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40  6396313600     1  DLEFT2  (3.0T)
  6396313640   629145600     4  (null)  (300G)
  7025459240   788577888        - free -  (376G)

:~ # gpart show  ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40  6396313600     1  freebsd-zfs  (3.0T)
  6396313640   629145600     4  freebsd-ufs  (300G)
  7025459240   788577888        - free -  (376G)

Again -s SIZE was ignored and all next free space was used.



I was able to repeat the test on another machine because i had a spare disk available. Fresh FreeBSD installation. Same version level. Same size of the partition layout but p1 was set to UFS.

:~ # gpart resize -a 4k -i 1 -s 2691000000 ada1
ada1p1 resized

The first time i got the same result as above. The -s was ignored and a resize to maximum was performed. The second time (cursor up, return) the size was set (reduced) correctly. That was reproducable. It needed two times of the same resize command to set the new size.

Suspected bug: gpart resize size switch calculation fails on partially partitioned disks.

Workaround as seen above: Add a new dummy partition of the expansion size. Add a fill partition on the rest of the disk. Delete the dummy partition. Resize the first partition with or without the -s switch. Delete the fill partition.

[i found more]

Back to the first system, same zpool, same disk model, same p1 layout, dummy partitions created:

:~ # gpart show -l ada4
=>        40  7814037088  ada4  GPT  (3.6T)
          40  2516582400     1  DLEFT1  (1.2T)
  2516582440   545259520        - free -  (260G)
  3061841960  1048576000     3  (null)  (500G)
  4110417960  1048576000     4  (null)  (500G)
  5158993960  1048576000     5  (null)  (500G)
  6207569960  1048576000     6  (null)  (500G)
  7256145960   545259520     7  (null)  (260G)
  7801405480    12631648        - free -  (6.0G)

#                       # 2516582400 old size
:~ # gpart resize -i 1 -s 2716582400 ada4
ada4p1 resized

:~ # gpart show -l ada4
=>        40  7814037088  ada4  GPT  (3.6T)
          40  2716582400     1  DLEFT1  (1.3T)
  2716582440   345259520        - free -  (165G)
[...]

?? Now it worked. SIZE is set as -s told.

:~ # gpart resize -i 1 -s 2730000000 ada4
ada4p1 resized

:~ # gpart show -l ada4
=>        40  7814037088  ada4  GPT  (3.6T)
          40  2730000000     1  DLEFT1  (1.3T)
  2730000040   331841920        - free -  (158G)
[...]

Worked again.

Now 274... with alignment:

:~ # gpart resize -a 4k -i 1 -s 2740000000 ada4
ada4p1 resized

:~ # gpart show -l ada4
=>        40  7814037088  ada4  GPT  (3.6T)
          40  3061841920     1  DLEFT1  (1.4T)
  3061841960  1048576000     3  (null)  (500G)
[...]

Failed. -s SIZE seems to be ignored when the -a ALIGNMENT is used.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2024-01-20 22:26:41 UTC
^Triage: this does not currently appear to be "In Progress".