Date: Mon, 12 May 2025 16:50:18 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 286746] "gpart add" with the "-a" and "-s" flags specified behaves unexpectedly Message-ID: <bug-286746-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286746 Bug ID: 286746 Summary: "gpart add" with the "-a" and "-s" flags specified behaves unexpectedly Product: Base System Version: 14.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: karl@denninger.net The documentation for gpart's "-a" flag to the "add" command says: -a alignment If specified, then the gpart utility tries to align start offset and partition size to be multiple of alignment value. It does indeed do this, including by changing the "-s" flag's size -- often by reducing it. That is, if you pass a "not-exactly an alignment boundary" size to "-s" gpart may create a smaller partition than you specified in order to end on said alignment boundary. This usually doesn't matter but in in a few cases it does, such as when nanobsd builds a "code slice" and then wants to "dd" it into the correct place. If gpart has reduced the "-s" size specified by even one block the copy fails. Alignment is extremely useful on modern storage devices, particularly SSDs and thus it would be nice to be able to specify this option in embedded builds where copying in a pre-built filesystem of known size to a target partition is used. Gpart will leave a "hole" in the partition table if necessary to meet alignment (e.g. the previous partition is not aligned on the requested boundary) which is expected behavior and does not cause trouble. However, shrinking the passed size argument unannounced, while harmless most of the time, definitely is not harmless when the created partition is a target of a copy-in, whether via dd or simply by filling the filesystem with files after it has been formatted. While the latter is an extreme corner case since you'd have to have a literally-full source filesystem the former, when building or updating embedded system images, is not. IMHO it should be considered to change gpart so it if a specified size is not on an alignment boundary it rounds up the specified size to the next boundary, but never down to the prior one. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-286746-227>