[Bug 286746] "gpart add" with the "-a" and "-s" flags specified behaves unexpectedly

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.