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

Re: Are the assigned capacities sufficient for my setup?



On Sun 02 Aug 2020 at 16:35:14 (-0500), Leslie Rhorer wrote:
> 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.

I think it's quite clear that we're talking about differences of scale
that, as I said, make this more appropriate for the NAS thread, and
not this one, where the OP was apportioning a disk with about 300GB
of free space available.

> > > 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.

For most laptops, the data "target" is going to be directories in
/home/<owner>/, and for people who don't separate /home from /, that's
going to be the / partition. Those who have chosen to dual-boot might
have set up a shared data partition, which is then quite likely to be
the largest.

> > > 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.

OK, so in the context of a laptop, this is typically going to be,
simply, partitions. Most people probably won't set up an array.

> > 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.

That's what I would call the idea (from the other thread) of putting a
laptop's /home on an external drive, RAID or not. But then again,
perhaps not for someone who's never travelled around giving
presentations from one, as so many people have been doing for years.

> > > 	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.

Perhaps this all makes sense to someone running a data centre, but
I can't see any reason for using RAID 1 in there. If a laptop doesn't
boot from its disk, then a bootable USB stick would be most people's
next step (most laptops having dropped optical media nowadays). But it
might not even be worth doing that if the disk has failed.

Cheers,
David.


Reply to: