\section{Partitioning}

\begin{frame}
   {Partition Organization}

   \begin{itemize}
      \item Disks are divided into \textbf{partitions}
      \item A partition is a physically contiguous region on the
      disk
      \item On the most common architectures, there are two
      partitioning schemes in use:
      \begin{itemize}
         \item \textbf{MBR} (Master Boot Record)
         \item \textbf{GPT} (GUID Partition Table)
      \end{itemize}
      \item \textbf{MBR} dates back to early days of
      \textbf{MSDOS}

      May have up to 4 \textbf{primary} partitions and one of
      the primary partitions can be designated as an
      \textbf{extended} partition subdivided into
      \textbf{logical} partitions with 15 partitions possible.

      \item \textbf{GPT} is on all modern systems and is based
      on \textbf{UEFI} (Unified Extensible Firmware Interface)

      By default may have up to 128 \textbf{primary}
      partitions

   \end{itemize}

\end{frame}

\cprotect\note{

   \begin{itemize}

      \item When using the \textbf{MBR} scheme:

      If we have a \textbf{SCSI} drive, for example
      \filelink{/dev/sda}, then \filelink{/dev/sda1} is the
      first primary partition and \filelink{/dev/sda2} is the
      second primary partition. If we created an extended
      partition \filelink{/dev/sda3} it could be divided into
      logical partitions. All partitions greater than four are
      logical partitions (meaning contained within an extended
      partition). There can only be one extended partition,
      but it can be divided into numerous logical partitions.

      \textbf{Note}: \textbf{Linux} does not require
      partitions to begin or end on cylinder boundaries, but
      other operating systems might complain if they do not.
      For this reason, the widely deployed \textbf{Linux}
      partitioning utilities try to play nice and end on
      boundaries.  Obviously partitions should not overlap
      either.

      \item When using the \textbf{GPT} scheme:

      There is no need for extended partitions, and you can
      have (by default) 128 primary partitions.

      Partitions can be up to $2^{33}$ TB in size! (with
      \textbf(MBR) the limit is just 2 TB.)
   \end{itemize}

}
\begin{frame}
   {Why Partition?}

   \begin{itemize}

      \item \textbf{Separation} of user and application data
      from operating system files

      \item \textbf{Sharing} between operating systems and/or
      machines

      \item \textbf{Security} enhancement by imposing different
      quotas and permissions for different system parts

      \item \textbf{Size} concerns; keeping variable and
      volatile storage isolated from stable

      \item \textbf{Performance} enhancement of putting most
      frequently used data on faster storage media

      \item \textbf{Swap} space can be isolated from data and
      also used for hibernation storage

   \end{itemize}
\end{frame}

\cprotect\note{

   Deciding what to partition and how to separate your
   partitions is cause for thought.  The reasons to have
   distinct partitions include increased granularity of
   security, quota, settings, or size restrictions.  You
   could also have distinct partitions to allow for data
   protection.

   A common partition layout contains a \filelink{/boot}
   partition, a partition for the root filesystem
   \filelink{/}, a swap partition, and a partition for
   the \filelink{/home} directory tree.

   Keep in mind that it is more difficult to re-size a
   partition after the fact than during install/creation
   time.  Plan accordingly.
}

\section{Partition Tables }

\begin{frame}
   {MBR Partition Table }

   \begin{multicols}{2}
      \large{
         \begin{itemize}
            \item The Partition table is in the last 64 bytes of the
            first sector, the 512 bytes of the \textbf{MBR}
            (\textbf{M}aster \textbf{B}oot \textbf{R}ecord)
            \item
            Each entry in the partition table is 16 bytes long and
            describes one of the four possible primary partitions.
            The information for each is:

            \begin{itemize}
               \item Active bit
               \item Beginning address in cylinder/head/sectors
               (\textbf{CHS}) format
               \item Partition type code, indicating: \textbf{Linux},
               \textbf{Linux LVM}, \textbf{ntfs}, \textbf{swap},
               etc
               \item Ending address in \textbf{CHS}
               \item Start sector, counting linearly from 0
               \item Number of sectors in partition
            \end{itemize}
            \columnbreak
            \textbf{Linux} only uses the last two fields for
            addressing using the linear block addressing
            (\textbf{LBA}) method.

         \end{itemize}
      }
      \begin{figure}[H]
         \includegraphics[width=2.0in]{IMAGES/partition_table}
         \caption{MBR Disk Partition Table}
      \end{figure}

   \end{multicols}
\end{frame}

\cprotect\note{

   The disk partition table is contained within the disk's
   \textbf{MBR} and is the 64 bytes following the 446 byte
   boot record.

   One partition on a disk may be marked active.  When the
   system boots, that partition is where the master boot
   loader looks for items to load.

   Remember that there can be only one extended partition,
   but that partition may contain a number of logical
   partitions.

   The structure of the \textbf{MBR} is defined by an
   operating system-independent convention.  The first 446
   bytes are reserved for the program code.  They typically
   hold part of a boot loader program.  The next 64 bytes
   provide space for a partition table of up to four
   entries.  The operating system needs this table for
   handling the hard disk.

   On \textbf{Linux} systems, the beginning and ending
   address in \textbf{CHS} is ignored.

   (Note for the curious, there are 2 more bytes at the end
   of the \textbf{MBR} known as the magic number, signature
   word, or end of sector marker, which always have the
   value \texttt{0x55AA}.)

}
\begin{frame}
   {GPT Partition Table }

   \begin{multicols}{2}
      \large{
         \begin{itemize}
            \item
            Modern hardware comes with \textbf{GPT} support; \textbf{MBR}
            support will gradually fade away
            \item
            The {Protective MBR} is for backwards compatibility so UEFI systems
            can be booted the old way.
            \item
            Two copies of \textbf{GPT} header, at beginning and end of disk,
            describing metadata:
            \begin{itemize}
               \item
               List usable blocks on disk
               \item
               Number of partitions
               \item Size of partition entries
            \end{itemize}
            \item
            Each partition entry has a minimum size of 128 bytes
         \end{itemize}
      }
      \begin{figure}[H]
         \includegraphics[width=2.6in]{IMAGES/GPT-Layout}
         \caption{GPT Disk Partition Table}
      \end{figure}
   \end{multicols}
\end{frame}

\cprotect\note{

   The \textbf{blkid} utility (to be discussed later) shows information
   about partitions:

   \begin{itemize}

      \item
      On a modern UEFI/GPT system::
      \begin{cmd}
 $ sudo blkid /dev/sda8
      \end{cmd}
      \vspace{-10pt}
      \begin{klst}[]
/dev/sda8: LABEL="RHEL8" UUID="53ea9807-fd58-4433-9460-d03ec36f73a3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0c79e35b-e58b-4ce3-bd34-45651b01cf43"
      \end{klst}
      \item
      On a legacy MBR system:
      \begin{cmd}
 $ sudo blkid /dev/sdb2
      \end{cmd}
      \vspace{-10pt}
      \begin{klst}[]
/dev/sdb2: LABEL="RHEL8" UUID="6921b738-1e36-429a-89be-8b97cf2f0556" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00022650-02"
      \end{klst}
   \end{itemize}

   Note both examples give a unique \verb?UUID? which
   describes the filesystem on the partition, not the
   partition itself.  It changes if the filesystem is
   reformatted

   The \textbf{GPT} partition also gives a \verb?PARTUUID?
   which describes the partition and stays the same even if the
   filesystem is reformatted.

   If the hardware supports it is possible to migrate a
   \textbf{MBR} system to \textbf{GPT}, but it is not hard to
   brick the machine while doing so.

   Thus, usually the benefits are not worth the risk.

}


