Bug 197989 - gpart(8) can't define start for new partition
Summary: gpart(8) can't define start for new partition
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: Andrey V. Elsukov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-24 11:21 UTC by timp87
Modified: 2015-03-05 10:14 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description timp87 2015-02-24 11:21:23 UTC
Hi! There is a problem with gpart(8) in some cases.

I have HP Proliant server with smart array raid controller (ciss driver).
Sometimes gpart(8) can't define the start of a new partition that I want to add.

Here is an example:

Two disks build into one mirror using HP Smart Array.
# gpart create -s gpt da0
da0 created

# gpart add -t freebsd-ufs -s 512k da0
ad0p1 added

# gpart show
=>  40   286677040   da0   GPT (137G)
    40         752         - free - (376K)
    792       1024     1   freebsd-ufs (512K)
   1816  286675264         - free - (137G)

# gpart add -t freebsd-ufs -s 512k da0
gpart: start '792': No space left on device

What? But I have free space on device. And why gpart(8) tries to add new partition from 792? I already have such partition. It should start from 1816!

Same story with MBR scheme, with 10.1-STABLE and 10.1-RELEASE.

Looks like gpart(8) is buggy.

FreeBSD 11.0-CURRENT amd64 r279210 (from 2015-02-23)
Comment 1 Andrey V. Elsukov freebsd_committer 2015-02-24 15:13:05 UTC
Can you show the output of the `geom disk list da0` command?
Comment 2 timp87 2015-02-24 18:36:06 UTC
(In reply to Andrey V. Elsukov from comment #1)
Yes, of course!

$ geom disk list da0
Geom name: da0
Providers:
1. Name: da0
   Mediasize: 146778685440 (137G)
   Sectorsize: 512
   Stripesize: 1048576
   Stripeoffset: 643072
   Mode: r0w0e0
   descr: HP RAID 1(1+0)
   lunid: 600508b1001033393620202020200019
   ident: P68AMP5396
   fwsectors: 32
   fwheads: 255
Comment 3 timp87 2015-02-25 07:41:06 UTC
The first partition has been added from 792 and it is a bit strange. Why not earlier? from 40 for example.
Comment 4 Andrey V. Elsukov freebsd_committer 2015-02-25 23:31:23 UTC
(In reply to timp87 from comment #3)
> The first partition has been added from 792 and it is a bit strange. Why not
> earlier? from 40 for example.

This is because your disk has logical block size equal to 1Mbyte and its first sector placed with 643072 bytes offset from the beginning of the hardware disk.

So, gpart(8) decided to properly align your first partition to start from the start of logical block.

[          PHYSICAL DISK           ]
---->[       da0                   ]
     ^ = 643072 bytes
[=======][=======][=======][=======] <- logical blocks
---------^ = 1048576 bytes

Now, when you created da0p1 partitions, it starts from the 792 sector:
643072 + 792*512 = 1048576 bytes.

Can you try this patch?

Index: sbin/geom/class/part/geom_part.c
===================================================================
--- sbin/geom/class/part/geom_part.c	(revision 279233)
+++ sbin/geom/class/part/geom_part.c	(working copy)
@@ -561,7 +561,7 @@ gpart_autofill(struct gctl_req *req)
 
 		s = find_provcfg(pp, "end");
 		first = (off_t)strtoimax(s, NULL, 0) + 1;
-		if (first > a_first)
+		if (first + offset > a_first)
 			a_first = ALIGNUP(first + offset, alignment);
 	}
 	if (a_first <= last) {
Comment 5 timp87 2015-02-26 09:44:30 UTC
(In reply to Andrey V. Elsukov from comment #4)
It works!

I added a couple of new partitions without any problems!

# gpart show
=>  40   286677040   da0   GPT (137G)
    40         752         - free - (376K)
   792        1024     1   freebsd-ufs (512K)
  1816        1024         - free - (512K)
  2840        1024     2   freebsd-ufs (512K)
  3864        1024         - free - (512K)
  4888        1024     3   freebsd-ufs (512K)
  5912        1024         - free - (512K)
  6936        1024     4   freebsd-ufs (512K)
  7960        1024         - free - (512K)
  8984       10240     5   freebsd-ufs (5.0M)
 19224        2048     6   freebsd-ufs (1.0M)
 21272   286655808         - free - (137G)




I also tried an 4k alignment:
# gpart create -s gpt da0
# gpart add -t freebsd-boot -a 4k -s 512k da0
da0p1 added, but partition is not aligned on 1048576
# gpart add -t freebsd-boot -a 4k -s 512k da0
da0p2 added, but partition is not aligned on 1048576
# gpart add -t freebsd-boot -a 4k -s 512k da0
da0p3 added, but partition is not aligned on 1048576
# gpart show
=>  40   286677040   da0   GPT (137G)
    40        1024     1   freebsd-boot (512K)
  1064        1024     2   freebsd-boot (512K)
  2088        1024     3   freebsd-boot (512K)
  3112   286673968         - free - (137G)

Is "partition is not aligned on 1048576" message important/dangerous?
Comment 6 timp87 2015-02-26 10:00:16 UTC
(In reply to timp87 from comment #5)
(In reply to Andrey V. Elsukov from comment #4)
ok, I understood if I want to set an alignment manually it will be aligned despite the logical block size. Your ascii picture is perfect! Thank you!
Hope this change will be MFCed to STABLE.
Comment 7 commit-hook freebsd_committer 2015-02-26 15:59:48 UTC
A commit references this bug:

Author: ae
Date: Thu Feb 26 15:59:46 UTC 2015
New revision: 279324
URL: https://svnweb.freebsd.org/changeset/base/279324

Log:
  When gpart(8) is trying automatically determine the first available
  block of free space after existing partition, take into account
  provider's stripeoffset, since the result will be adjusted to this
  value.

  PR:		197989
  MFC after:	1 week

Changes:
  head/sbin/geom/class/part/geom_part.c
Comment 8 commit-hook freebsd_committer 2015-03-05 10:07:53 UTC
A commit references this bug:

Author: ae
Date: Thu Mar  5 10:07:10 UTC 2015
New revision: 279645
URL: https://svnweb.freebsd.org/changeset/base/279645

Log:
  MFC r279324:
    When gpart(8) is trying automatically determine the first available
    block of free space after existing partition, take into account
    provider's stripeoffset, since the result will be adjusted to this
    value.

    PR:		197989

Changes:
_U  stable/9/sbin/geom/class/part/
  stable/9/sbin/geom/class/part/geom_part.c
Comment 9 commit-hook freebsd_committer 2015-03-05 10:08:54 UTC
A commit references this bug:

Author: ae
Date: Thu Mar  5 10:08:37 UTC 2015
New revision: 279646
URL: https://svnweb.freebsd.org/changeset/base/279646

Log:
  MFC r279324:
    When gpart(8) is trying automatically determine the first available
    block of free space after existing partition, take into account
    provider's stripeoffset, since the result will be adjusted to this
    value.

    PR:		197989

Changes:
_U  stable/10/
  stable/10/sbin/geom/class/part/geom_part.c
Comment 10 commit-hook freebsd_committer 2015-03-05 10:12:56 UTC
A commit references this bug:

Author: ae
Date: Thu Mar  5 10:12:29 UTC 2015
New revision: 279647
URL: https://svnweb.freebsd.org/changeset/base/279647

Log:
  MFC r279324:
    When gpart(8) is trying automatically determine the first available
    block of free space after existing partition, take into account
    provider's stripeoffset, since the result will be adjusted to this
    value.

    PR:        197989

Changes:
_U  stable/8/sbin/geom/class/part/
  stable/8/sbin/geom/class/part/geom_part.c