Bug #1547
open
disklabel64 automatic sizing
Description
disklabel64 is a prime example for unintuitive behavior:
- it requires an arbitrary 4KB aligment on sizes and offset
- size aligments seem to be enforced directly, but offset alignments are
not. offsets just show up as "ILLEGAL" when re-editing the label. no
complaint before - automatic sizing using "*" does not work:
d: * * HAMMER
but then:
partition d: size out of bounds (4825292800)
the size is completely off, roughly by a factor of 10(!)
I had to do:
d: 4 * HAMMER
and then re-edit to make it read
d: * 4712200 HAMMER
- there is no way to change the display block size
- there is no way to specify sector counts or byte counts in size/offset
Updated by tuxillo over 13 years ago
Hi Simon,
disklabel64 is now the default in DFBSD. If I edit the label:
vmware# disklabel -e da1s116 partitions:
- size offset fstype fsuuid
- EXAMPLE
#a: 4g 0 4.2BSD
a: * * HAMMER
vmware# disklabel da1s1 | grep -v '^#'
diskid: 46d8283c-7705-11e0-996e-010c29c5ae30
label:
boot2 data base: 0x000000001000
partitions data base: 0x000000100200
partitions data stop: 0x01f3ffd3a000
backup label: 0x01f3ffd3a000
total size: 0x01f3ffd3b800 # 2047997.23 MB
alignment: 4096
display block size: 1024 # for partition display only
16 partitions:
a: 2097148132 0 HAMMER # 2047996.223MB
a-stor_uuid: 5a870493-7705-11e0-996e-010c29c5ae30
Automatic sizing seems to work, how did you do it?
About the aligning thing I think there have been some changes since you opened
this ticket (5179f0c55e7c654343dd160417a86e1d4a3870de,
4921cba1f62ca52955e529f9b60fa2fd23821d80).
Cheers,
Antonio Huete
Updated by corecode over 13 years ago
I don't remember exactly what I did. Given that the example lists the "d"
partition, maybe I tried adding a partition after existing ones?
The two bottom points probably still apply.
Updated by tuxillo almost 11 years ago
- Description updated (diff)
- Category set to Userland
- Status changed from New to In Progress
- Assignee changed from 0 to tuxillo
- Target version set to 3.8
Grab.