Bug 197989
| Summary: | gpart(8) can't define start for new partition | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Pavel Timofeev <timp87> |
| Component: | bin | Assignee: | Andrey V. Elsukov <ae> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | ae |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
Can you show the output of the `geom disk list da0` command? (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 The first partition has been added from 792 and it is a bit strange. Why not earlier? from 40 for example. (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) { (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? (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. 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 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 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 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 |
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)