The disk1s*
in /dev/disk1s*
are identifiers for the APFS volumes and snapshot in the container with the identifier disk1
. These are not partitions as stated in your question. The APFS container resides in either a single partition on a drive or two partition on separate drives. In your example, the APFS volumes and snapshot all share in the same APFS container. Below shows the sum of the volumes, snapshot and available space equal the APFS container size. There is no lost of space.
disk1s5s1 14. Gi
disk1s4 5. Gi
disk1s2 0.320 Gi
disk1s6 0.001 Gi
disk1s1 192. Gi
disk1s3 .569 Gi
Available 22. Gi
------------
Size 233. Gi
Note: You did not include in your question the size of the unmounted Recovery volume (disk1s3
). The value of 569 MiB came from my Big Sur installation. This value should be the same on your Big Sur installation.
Below was taken from man diskutil
. I edited out the text that does not directly relate to the OP's question.
You are referring to disk identifiers. In your example, the (BSD) disk identifier string variously identifies a virtual logical volume. It will take the form of diskCsV
, or diskCsVsS
where C
, S
, and V
are positive decimal integers (possibly multi-digit), and where:
C
is an APFS Container. This is a virtual disk constructed by
APFS to represent a collection of APFS Volumes. Multiple APFS
Containers can be active simultaneously.
V
is an APFS Volume; it refers to a virtual logical volume that
is shared out of an APFS Container. For example, exported from
an APFS Container designated as disk1
there might be an APFS
Volume disk1s1
, mountable as a file system and usable for file
storage via its mountpoint path.
S
is an APFS Snapshot; it refers to a frozen moment in time of
the state of files on an APFS Volume. For example, if APFS
Container disk6
has an APFS Volume disk6s3
, and two APFS Snapshots
have been "taken" on it, these, when mounted, might be
designated as disk6s3s1
and disk6s3s2
. Zero or more snapshots
can be persistently defined on a volume, but only "active"
(mounted) snapshots have disk identifiers.
It is important for software to avoid relying on numerical ordering of
any of the parts. Activities including but not limited to partition
deletions and insertions, partition resizing, virtual volume deletions
and additions, device ejects and attachments due to media insertion
cycles, plug cycles, authentication lock cycles or reboots, can all cause
(temporary) gaps and non-increments in the numerical ordering of any of
the parts. You must rely on more persistent means of identification, such
as the various UUIDs.