On 8/2/2020 2:54 PM, David Wright wrote:
I never said it does. It does take up a little space, but not a
significant amount. What does take up space is /home, which can get
to be huge. Even on a laptop, making /home a part of the largest
partition is a good idea.
What it sharing the partition with /home? And what is it's
mountpoint?
On my big servers, it doesn't have a mount point. For consistency
sake, the mount point for the data array on all the servers is /RAID,
and the array is /dev/md0, which consists of varying numbers of
individual drives (eight drives each plus one spare for the big servers)
in a RAID 6 array. On md0, I have a directory named home, which of
course becomes /RAID/home when the md0 array is mounted. On all the
systems, I have two SSDs set up with three partitions each, the first
two of which are assembled int RAID 1 arrays. The second array,
/dev/md2, is mounted on /, and a symlink points from /home to /RAID/home.
Giving it its own partition permanently
sequesters any space allocated to the purpose, to no particular
advantage. Making it simply a directory on the largest drive target
frees up all the unused space for other use. Even on most laptops,
the largest partition is usually not /,
Which one is, usually?
The data target. On my servers, this is /RAID, which is anywhere from
9T to 48T. On my workstations, this varies some depending upon whether
the system is multi-boot or single boot, but it is usually named /DATA.
It may be NTFS or EXT4. It may r may not be a separate physical target,
whether it is an array, a separate drive, or a separate partition on one
drive.
and in any case, as mentioned
previously, it is generally better for / and /home to be on separate
targets.
In the previous post, we had "data array" aka "data repository",
SSDs for booting, and a NAS or file server (whose data repository
needs to be huge), plus a "single set of array spindles".
With that wide choice, I'm not clear what "targets" are, nor how
A file system target is a logical storage location where a file system
can be created. It can be an unpartitioned drive, a partition on a
drive, an array, a tmpfs system, a RAM drive, or a loop device.
all these different items are arranged with respect to the PC
itself (or which are entirely separate entities).
In Linux, it can be done just about anyway one likes, although some
topologies are rather senseless.
Journalling is only a safety mechanism if the file system is being
written. Since /boot is to all intents and purposes never written,
journaling does nothing for it. The /boot partition can be mounted
read-only, as a matter of fact.
What are the benefits of /boot on a RAID?
The same as any other data repository. RAID 0 would make no sense at
all, because /boot is rather tiny, and RAID 0 offers no redundancy at
all. RAID 1 is perfect, however, allowing double or triple (or more)
drive redundancy, virtually guaranteeing the system will boot even if a
drive (or even two or three drives) fails. Higher level RAID targets
don't really provide any significant features for the boot system, and
especially not /boot. They really don't provide much for /, either,
given its relatively small requirements.
Does that mean that a RAID
has to be assembled even before the PC can boot up?
Not if it is a RAID 1. A RAID 1 member is identical to any other
target except for the addition of an MD superblock. The I/O system only
needs to be able to read the filesystem. It can be completely ignorant
of the RAID 1 superblock - at least for superblock versions 1.0 and
above. On a non-EFI, non-ZFS system, everything the system needs to
boot is in the /boot directory.
Indeed, the RAID 1 superblock can be added to or removed from almost
any target to make it a part of an array or remove it from the array
without touching the MBR, the partition table, file systems, or the data
on the drive. GRUB, or whatever bootloader one chooses, can read the
contents of /boot from any one of the array members without
understanding anything about arrays, or with only one - any one - of the
RAID mirrors present. It does not have to assemble the array, and in
fact I don't think it does, or at least it did not in earlier versions
of GRUB. The same is actually true of any RAID 1 array, although it is
not a good idea to mount a single array member, as opposed to mounting a
single member RAID 1 array. The bootloader will load the kernel, which
*MUST* know how to assemble the arrays before mounting. For RAID 1, it
is not necessary for the bootloader to understand anything about arrays,
and in fact to my knowledge GRUB does not.
Note while GRUB does not need to know the details of a version 1.0 or
above RAID 1 array containing the /boot directory, it *DOES* need to
know enough about the filesystem to read it.