Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225502 > unrolled thread

Re: Are the assigned capacities sufficient for my setup?

Back to article view | Back to linux.debian.user

Contents

  Re: Are the assigned capacities sufficient for my setup? Charlie Gibbs <cgibbs@surfnaked.ca> - 2020-07-29 20:10 +0200
    Re: Are the assigned capacities sufficient for my setup? David Wright <deblis@lionunicorn.co.uk> - 2020-07-30 04:20 +0200
    Re: Are the assigned capacities sufficient for my setup? Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-30 04:40 +0200
    Re: Are the assigned capacities sufficient for my setup? Leslie Rhorer <lesrhorer@att.net> - 2020-08-02 02:30 +0200
      Re: Are the assigned capacities sufficient for my setup? Dan Ritter <dsr@randomstring.org> - 2020-08-02 05:50 +0200
        Re: Are the assigned capacities sufficient for my setup? David Wright <deblis@lionunicorn.co.uk> - 2020-08-02 06:20 +0200
        Re: Are the assigned capacities sufficient for my setup? Leslie Rhorer <lesrhorer@att.net> - 2020-08-02 21:20 +0200
          Re: Are the assigned capacities sufficient for my setup? David Wright <deblis@lionunicorn.co.uk> - 2020-08-02 22:00 +0200
            Re: Are the assigned capacities sufficient for my setup? Leslie Rhorer <lesrhorer@att.net> - 2020-08-02 23:40 +0200
              Re: Are the assigned capacities sufficient for my setup? David Wright <deblis@lionunicorn.co.uk> - 2020-08-11 06:20 +0200

#225502 — Re: Are the assigned capacities sufficient for my setup?

On Wed Jul 29 08:39:26 2020 Andrew Cater <amacater@gmail.com> wrote:

 > You _can_ use guided partitioning as a guide. Use Windows to
 > reduce the amount of space it takes on the disk. Use Windows
 > tools to format the second half of the disk, or whatever to vfat.

Note that with NTFS you can't shrink the Windows partition to less
than half its size.  NTFS creates a Master File Table smack in the
middle of the partition, and it's immovable.  Well, generally -
if you go to https://www.raxco.com you'll find a utility called
PerfectDisk, which with minor handwaving and a reboot or two can
move the MFT.  You can download a demo that will work long enough
to do the job.  Repeat as necessary; I shrank the NTFS partition
on my formerly Windows-only laptop from 250GB down to 45GB.

As for partition sizing, I set up my machines with three partitions:
/, /home, and swap.  If you're going to be installing lots of software
on your machine (especially games), I'd recommend setting aside 20 or
30 gigabytes for /, since /usr can get pretty large.  I learned this
the hard way after getting caught behind the 8-ball after a kernel
upgrade.  Fortunately, gparted came to the rescue, allowing me to
shave 10GB off /home and give it to /.  I use the old rule of thumb
of twice memory size for swap, and give what's left to /home.

You definitely want /home in its own partition - it makes life
much easier when doing upgrades, since you can completely wipe
out / while leaving /home intact.  (Needless to say, though, I
back up /home regularly, plus /etc and /usr for good measure.)

BTW please don't top-post.  Not all of us are Jeopardy fans.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
  X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [next] | [standalone]

#225514

On Wed 29 Jul 2020 at 09:38:56 (-0700), Charlie Gibbs wrote:
> On Wed Jul 29 08:39:26 2020 Andrew Cater <amacater@gmail.com> wrote:
> 
> > You _can_ use guided partitioning as a guide. Use Windows to
> > reduce the amount of space it takes on the disk. Use Windows
> > tools to format the second half of the disk, or whatever to vfat.
> 
> Note that with NTFS you can't shrink the Windows partition to less
> than half its size.  NTFS creates a Master File Table smack in the
> middle of the partition, and it's immovable.  Well, generally -
> if you go to https://www.raxco.com you'll find a utility called
> PerfectDisk, which with minor handwaving and a reboot or two can
> move the MFT.  You can download a demo that will work long enough
> to do the job.  Repeat as necessary; I shrank the NTFS partition
> on my formerly Windows-only laptop from 250GB down to 45GB.

I would call that a little pessimistic (though not your end-result).
I reclaimed 61% of a Windows partition using only its own tools.

Here are my notes (indented) of what I did, and some annotations:

    Type here to search → Control Panel
    System and Security
    Administrative Tools
    Free up disk space, then Defragment and optimise drives
    https://technet.microsoft.com/en-us/library/cc731894(v=ws.11).aspx

BTW I have no idea what "optimise drives" means or does.

    Type here to search → Disk Manager
    Create and format hard disk partitions
    Click on C:
    RightClick on C:
    Shrink Volume…

    gives ~38GB

ie, a small amount so far, indeed.

    I haven't managed to force shrink to attempt to move a file and
    reveal which file is causing the problem.

But this was sufficient to hold the owner's most important files, so …

    Click on free space
    RightClick on free space
    New Simple Volume
    M:
    NTFS

    File manager
    Copy selected directories of [owner]'s files to M:
    Deleted the originals on C: (in Documents)

    Using
    https://www.disk-partition.com/articles/shrink-volume-with-unmovable-files-4348.html

    Type here to search → System Protection
    Set no protection on C:
    Delete all existing checkpoints

    That was enough to be able to shrink the partition sufficiently.

… by repeating the first steps above.

I copied the files back to C: afterwards, of course, and deleted M:.

The following was repeated five times …

    A new partition was made in windows and formatted at exFAT with
    the name linuxlinux for identification purposes.

    In Disk Manager, Click on the free space, then RightClick on it.
    New Simple Volume
    Set the size
    Assign no letter
    exFAT or FAT as offered
    Volume Name as appropriate (will be changed later)
    Finish

    Repeat as necessary.

… to convert one Windows partition into:

5          4892672       347348991   163.3 GiB   0700  Basic data partition
6        347348992       429268991   39.1 GiB    8300  Linux-A
7        429268992       511188991   39.1 GiB    8300  Linux-B
8        511188992       883275775   177.4 GiB   8300  Linux-Home
9        883275776       883292159   8.0 MiB     EF02  Linux-BIOS-Boot ¹
10       883292160       892084223   4.2 GiB     8200  Linux-Swap

where 5 is the remaining shrunken remnant, 39% of the original.
Note that all the heavy lifting was done with Windows' own software,
so that it would have no reason to be unhappy with the result.
I then changed the partition information (type code, LABEL and
PARTLABEL) in linux, and returned to Windows to tell it to
completely ignore these partitions. This last is to avoid Windows
nagging about wanting to reformat these strange partitions.)

> As for partition sizing, I set up my machines with three partitions:
> /, /home, and swap.  If you're going to be installing lots of software
> on your machine (especially games), I'd recommend setting aside 20 or
> 30 gigabytes for /, since /usr can get pretty large.  I learned this
> the hard way after getting caught behind the 8-ball after a kernel
> upgrade.  Fortunately, gparted came to the rescue, allowing me to
> shave 10GB off /home and give it to /.

I made my (twin) root partitions a little on the generous side, as
I intended at some time in the future to wipe the rest of the disk
and devote it to linux. During the ascendancy of this laptop, both
root filesystems (one stretch, the other buster) have hosted the
apt-cacher-ng cache for jessie/stretch/buster i386/amd64 installations.

(With hardware rot, the machine's future is no longer so assured.
It no longer runs my apt-cacher-ng cache.)

> I use the old rule of thumb
> of twice memory size for swap, and give what's left to /home.

OTOH I think I was rather generous with swap (1 x 4GB memory).
About the only thing that disturbs it is xpdf's current memory
leak (#926501/#942086/#945188).

> You definitely want /home in its own partition - it makes life
> much easier when doing upgrades, since you can completely wipe
> out / while leaving /home intact.

Agreed. It also simplifies encrypting /home if it's in a separate
partition (swap too). I don't encrypt root because it complicates
remote booting/unlocking.

> (Needless to say, though, I
> back up /home regularly, plus /etc and /usr for good measure.)
> 
> BTW please don't top-post.  Not all of us are Jeopardy fans.

¹ I boot linux with the BIOS, so Grub needs this reserved area
  for its Stage 2.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225515

> than half its size.  NTFS creates a Master File Table smack in the
> middle of the partition, and it's immovable.  Well, generally -

Are you really sure?  I had the vague impression that `ntfsresize`
acquired the ability to move those "immovable" files more than 10
years ago.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225719

On 7/29/2020 11:38 AM, Charlie Gibbs wrote:
> As for partition sizing, I set up my machines with three partitions:
> /, /home, and swap.

	I don't implement a separate partition for /home.  Instead, I place it 
on my data array where it gets backed up nightly, then a create a 
symlink to /RAID/home from the root directory.  That way, the user's 
files can grow to be as gargantuan as they like, they have protected 
backups, and I don't have to worry about upgrades.

>  If you're going to be installing lots of software
> on your machine (especially games), I'd recommend setting aside 20 or
> 30 gigabytes for /, since /usr can get pretty large.  I learned this
> the hard way after getting caught behind the 8-ball after a kernel
> upgrade.  Fortunately, gparted came to the rescue, allowing me to
> shave 10GB off /home and give it to /.  I use the old rule of thumb
> of twice memory size for swap, and give what's left to /home.

	By moving /home to the data array, I leave plenty of breathing space 
for /.  Since I am using SSDs for booting, I get a little generous and 
use 40GB total of swap - 20G from each drive - with 16G of memory.  I 
allocate a generous 200M of space to a /boot partition on each drive 
assembled into a RAID 1 array formatted as ext2.  Since /boot almost 
never gets written, there is no need for journalling.  That leaves a 
full 98G for / on a pair of 128G SSDs.  These can be had for as little 
as $18 each, these days.

> You definitely want /home in its own partition - it makes life
> much easier when doing upgrades, since you can completely wipe
> out / while leaving /home intact.  (Needless to say, though, I
> back up /home regularly, plus /etc and /usr for good measure.)

	I agree /home is best kept separate from /, but I disagree it is better 
to give it it's own partition on a NAS or file server.  I agree it is a 
good idea on a workstation or an embedded system, where all of the 
partitions may be somewhat limited, and in particular where there may be 
only a single hard drive or a single set of array spindles.  On a NAS or 
file server, however, the data repository needs to be huge, and given 
that /home is a lot more volatile than /, or especially /boot, I think 
putting /home on the data repository is a better idea.  After all, why 
limit its size while simultaneously eating up space that some day might 
be needed by /?  That, plus the drive(s) used by the boot system will 
likely last a lot longer if not subjected to the thrashing inherent in 
the /home directories.

[toc] | [prev] | [next] | [standalone]

#225725

Leslie Rhorer wrote: 
> On 7/29/2020 11:38 AM, Charlie Gibbs wrote:
> > As for partition sizing, I set up my machines with three partitions:
> > /, /home, and swap.
> 
> 	I don't implement a separate partition for /home.  Instead, I place it on
> my data array where it gets backed up nightly

This may be a problem for the original poster, who has only
admitted to a laptop, nothing else.

> RAID 1 array formatted as ext2.  Since /boot almost never gets written,
> there is no need for journalling.  That leaves a full 98G for / on a pair of

I don't understand why you think journalling takes an excessive
amount of space, or why you would go out of your way to turn it
off. Ever. Turning off safety mechanisms is generally not
something anyone should advocate without a big flashing warning
sign.

-dsr-

[toc] | [prev] | [next] | [standalone]

#225728

On Sat 01 Aug 2020 at 23:43:17 (-0400), Dan Ritter wrote:
> Leslie Rhorer wrote: 
> > On 7/29/2020 11:38 AM, Charlie Gibbs wrote:
> > > As for partition sizing, I set up my machines with three partitions:
> > > /, /home, and swap.
> > 
> > 	I don't implement a separate partition for /home.  Instead, I place it on
> > my data array where it gets backed up nightly
> 
> This may be a problem for the original poster, who has only
> admitted to a laptop, nothing else.

I wondered whether LH's post was accidentally posted to this thread
rather than in "Homebuilt NAS Advice" where it seems more relevant.
I had a hard time understanding the jargon—the OP still seems to be
learning about partitions, mountpoints, and what /home is for.

> > RAID 1 array formatted as ext2.  Since /boot almost never gets written,
> > there is no need for journalling.  That leaves a full 98G for / on a pair of
> 
> I don't understand why you think journalling takes an excessive
> amount of space, or why you would go out of your way to turn it
> off. Ever. Turning off safety mechanisms is generally not
> something anyone should advocate without a big flashing warning
> sign.

I've seen this advice in the past. I suppose there was a time when
people might have needed to mount /boot with an old rescue CD that
couldn't mount a filesystem having modern bells and whistles.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225748

On 8/1/2020 10:43 PM, Dan Ritter wrote:
> Leslie Rhorer wrote:
>> On 7/29/2020 11:38 AM, Charlie Gibbs wrote:
>>> As for partition sizing, I set up my machines with three partitions:
>>> /, /home, and swap.
>>
>> 	I don't implement a separate partition for /home.  Instead, I place it on
>> my data array where it gets backed up nightly
> 
> This may be a problem for the original poster, who has only
> admitted to a laptop, nothing else.

	I must have missed that.

>> RAID 1 array formatted as ext2.  Since /boot almost never gets written,
>> there is no need for journalling.  That leaves a full 98G for / on a pair of
> 
> I don't understand why you think journalling takes an excessive
> amount of space

	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.  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 /, and in any case, as mentioned previously, it is generally 
better for / and /home to be on separate targets.  This does not mean 
/home has to be on a separate partition of its own.

, or why you would go out of your way to turn it
> off. Ever. Turning off safety mechanisms is generally not
> something anyone should advocate without a big flashing warning
> sign.

	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.

[toc] | [prev] | [next] | [standalone]

#225751

On Sun 02 Aug 2020 at 14:09:50 (-0500), Leslie Rhorer wrote:
> On 8/1/2020 10:43 PM, Dan Ritter wrote:
> > Leslie Rhorer wrote:
> > > On 7/29/2020 11:38 AM, Charlie Gibbs wrote:
> > > > As for partition sizing, I set up my machines with three partitions:
> > > > /, /home, and swap.
> > > 
> > > 	I don't implement a separate partition for /home.  Instead, I place it on
> > > my data array where it gets backed up nightly
> > 
> > This may be a problem for the original poster, who has only
> > admitted to a laptop, nothing else.
> 
> 	I must have missed that.
> 
> > > RAID 1 array formatted as ext2.  Since /boot almost never gets written,
> > > there is no need for journalling.  That leaves a full 98G for / on a pair of
> > 
> > I don't understand why you think journalling takes an excessive
> > amount of space
> 
> 	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?

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

> 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
all these different items are arranged with respect to the PC
itself (or which are entirely separate entities).

> This does not mean /home has to be on a separate partition
> of its own.
> 
> , or why you would go out of your way to turn it
> > off. Ever. Turning off safety mechanisms is generally not
> > something anyone should advocate without a big flashing warning
> > sign.
> 
> 	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? Does that mean that a RAID
has to be assembled even before the PC can boot up?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225756

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.

[toc] | [prev] | [next] | [standalone]

#226092

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web