https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250609
Bug ID: 250609
Summary: gpart resize: bug in combined -a -s usage
Product: Base System
Version: 12.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: gwbr0...@yahoo.de
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
