[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are the assigned capacities sufficient for my setup?





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.


Reply to: