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

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

mdadm usage

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

Contents

  mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 08:10 +0100
    Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-29 08:30 +0100
      Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-29 09:40 +0100
    Re: mdadm usage Felix Miata <mrmazda@earthlink.net> - 2020-12-29 08:50 +0100
      Re: mdadm usage basti <mailinglist@unix-solution.de> - 2020-12-29 09:40 +0100
        Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 21:40 +0100
          Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-30 00:00 +0100
          Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 02:00 +0100
            Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 02:30 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 09:20 +0100
              Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-30 14:40 +0100
                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
                  Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2021-01-02 14:40 +0100
                mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                  Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                    Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 21:50 +0100
                      Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 22:40 +0100
                        Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 23:20 +0100
                          Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 00:30 +0100
                            Re: mdadm usage rhkramer@gmail.com - 2020-12-31 13:30 +0100
                              Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-31 15:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 15:30 +0100
                          Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 15:50 +0100
                            Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:10 +0100
                              Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 16:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:40 +0100
                                  Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-01 23:10 +0100
                                    Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 09:40 +0100
                                      Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 10:10 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 11:30 +0100
                                        Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 14:50 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 16:40 +0100
                                            Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 18:10 +0100
                                      Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 10:40 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:00 +0100
                                          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 12:30 +0100
                                            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:50 +0100
                                              Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 13:10 +0100
                                                Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:20 +0100
                                              Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:10 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 12:50 +0100
            Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-30 11:50 +0100
              Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-30 13:30 +0100
              Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 13:30 +0100
              Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 22:10 +0100
                Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-31 00:00 +0100
          Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 09:10 +0100
        Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 04:00 +0100
    Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-29 14:20 +0100
      Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-29 16:40 +0100
        Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-29 20:40 +0100
        Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 14:40 +0100
          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2020-12-30 14:50 +0100
          Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-30 18:00 +0100
            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 19:40 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#230242

Andrei POPESCU wrote:

> My laptop is indeed on a 30 GiB partition, but using only 14 GiB. I do
> (auto)clean the package cache more or less regularly though, even on
> unstable installs.

Hi Andrei,
thank you for sharing your thoughts.

# df -hl .
Filesystem      Size  Used Avail Use% Mounted on
/dev/md1         30G   21G  7.6G  74% /

It has MySQL, Apache, DNS, SAMBA and some others, but size is stable over
the past 10y.

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

#230117

When i enter mdadm --examine /dev/sdb

I get:

/dev/sdb:

    MBR Magic: aa55

Partition[0] : 3907026944 sectors at         2048 (type 83)


So I thought I was good. I then tried to reassemble:

mdadm -A -R /dev/md0 /dev/sdb  

I get:

mdadm: cannot assembler mbr metadata on /dev/sdb

So, I tried it on sdb1

mdadm: /dev/sdb1 has no superblock - assembly aborted


it could all very well be, that I have borked these two drives. It's not
the end of the world, there was no data loss, and the data was already
transferred off of them. And, my lesson has been learned. RAID sounds
all good and dandy, and does provide some protection against data loss
caused by hardware failure.


Which bring me to my final question, just for closure.

If hardware raid (like if I bought a controller), would it be any
different, if I removed the drives and just put on one another machine
-- would I be able to see the data on it like a normal drive? Or would I
run into the same issue??


On 30.12.20 01:53, deloptes wrote:
> Thomas A. Anderson wrote:
>
>> Once I can get anything off one of these two drives, I will then switch
>> my current setup to 1 drive (8TB), with an attached 8TB drive that will
>> be be backup --weekly, or whatever.
> you can start one of the drives that was member of raid1 array on any
> computer, just as Reco said by assembling the mdraid on that computer.
>
> Check mdadm man page.
>
> For example I attached a disk that was member of raid through a USB storage
> box:
>
> * Examine the RAID table
>
>  mdadm --examine /dev/sdj
>  /dev/sdj:
>     MBR Magic : aa55
>  Partition[0] :       997376 sectors at         2048 (type fd)
>  Partition[1] :    156250112 sectors at       999424 (type fd)
>  Partition[2] :   1796272130 sectors at    157251582 (type 05)
>
> * Assemble and run the RAID array with one disk
>
>  mdadm -A -R /dev/md0 /dev/sdj1
>  mdadm: /dev/md0 has been started with 1 drive (out of 2).
>  
>  mdadm -A -R /dev/md1 /dev/sdj2
>  mdadm: /dev/md1 has been started with 1 drive (out of 2).
>  
>  mdadm -A -R /dev/md2 /dev/sdj5
>  mdadm: /dev/md2 has been started with 1 drive (out of 2).
>
> Now I can do whatever I want with those partitions
>

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

#230118

[Multipart message — attachments visible in raw view] — view raw

On 30.12.2020 15:42, Thomas A. Anderson wrote:
> it could all very well be, that I have borked these two drives. It's not
> the end of the world, there was no data loss, and the data was already
> transferred off of them. And, my lesson has been learned. RAID sounds
> all good and dandy, and does provide some protection against data loss
> caused by hardware failure.
It appears to be misconfigured, because at least partition type should 
be "fd". Not "83" as in your case, which looks like VMWare Storage 
partition type.
I'm not a VMWare expert so I can't give any advice here.
Now it looks like you've dealing with some advanced system configuration 
and virtualization, not with a simple one like plain hardware and 2 drives.

> Which bring me to my final question, just for closure.
>
> If hardware raid (like if I bought a controller), would it be any
> different, if I removed the drives and just put on one another machine
> -- would I be able to see the data on it like a normal drive? Or would I
> run into the same issue??
The only advantage hardware raid controller (not a simple HBA) could 
offer is a performance. But it also adds an additional point of failure 
- the raid controller itself.
When hardware raid controller fails, in most cases, you have to replace 
it with the same model, or if same model won't be available due to EoL 
or discontinuity,
with a compatible one from the same make\brand, to reassemble RAID array 
on the drives and access data.
The trend of the industry seems to be going away from hardware raid 
solutions, replacing them with software defined solutions.

In case of software defined RAID, like "mdraid" or "Microsoft Storage 
Spaces", you can reassemble array and access data on another machine.
Speaking of "mdraid", with properly configured RAID1, you can even use a 
single drive from the array to access data on another machine.
If this will be a drive with working OS, it will boot up normally and 
report about degraded state of RAID1 array and about missing one (or 
more if it's a three-way mirror) of it's member drives.


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

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

#230119

Thomas A. Anderson wrote: 
> Which bring me to my final question, just for closure.
> 
> If hardware raid (like if I bought a controller), would it be any
> different, if I removed the drives and just put on one another machine
> -- would I be able to see the data on it like a normal drive? Or would I
> run into the same issue??

Much worse.

If you had done this correctly, you can take a set of drives
from a working mdadm system and bring them to another computer
and use mdadm to import them and use them. Depending on which
options you chose and which drives you brought over, you could
potentially do this with fewer drives than "all".

(The same is true of ZFS and BTRFS.)

On every hardware RAID system that I know of, you need the same
hardware RAID on the receiving system -- sometimes just a
compatible card, sometimes precisely the same card.

-dsr-

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

#230123

On Wed, Dec 30, 2020 at 11:42:37AM +0100, Thomas A. Anderson wrote:
> When i enter mdadm --examine /dev/sdb
> 
> I get:
> 
> /dev/sdb:
> 
>     MBR Magic: aa55
> 
> Partition[0] : 3907026944 sectors at         2048 (type 83)

It would say more than that if sdb had ever been an md RAID member.

Are you sure it was sdb? Could it have been a partition on sdb?
"fdisk -l /dev/sdb" to list partitions. Also be really careful that
sdb really is the device you think it is!

> If hardware raid (like if I bought a controller), would it be any
> different, if I removed the drives and just put on one another machine
> -- would I be able to see the data on it like a normal drive? Or would I
> run into the same issue??

You would run into the same issue but it would be worse because the
other computer would have to have the same brand (possibly even the
exact same model) of hardware RAID. Every RAID system has to put
metadata onto the devices.

With mdadm, the structure on disk is public information. If you run
into difficulty you can get help from a wide pool of people. I have
seen data brought back from some truly disastrous situations in
threads on the linux-raid mailing list (where mostly md-related
things are discussed).

Try the same thing with hardware RAID and your only port of call is
the manufacturer's support desk because the layout of your data is
now proprietary information. For most of us the support desks of
such vendors don't work out well.

In many cases hardware RAID performs better, especially if you get
one with a supercap-backed write cache, but the trend these days is
to do Just a Bunch of Disks (JBOD) with software RAID, btrfs or
zfs.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#230145

Thomas A. Anderson wrote:

> If hardware raid (like if I bought a controller), would it be any
> different, if I removed the drives and just put on one another machine
> -- would I be able to see the data on it like a normal drive? Or would I
> run into the same issue??

if you choose using hardware raid over software raid, then the management of
the RAID depends on the controller. This means you have to use the
management tools provided by the manufacturer and in order to use this disk
on another computer, you have to make sure that the other computer has also
the same controller (I mean exactly the same).
Also mdadm provides monitoring and email notification, which in case of
hardware raid can also be done, but is more exotic or would require
something like SNMP.
It might be common in some vendor specific server hardware, but I usually
avoid it on no brand PC. IMO there is more disadvantage than advantage in
using hardware raid.

Regarding you issue with recovering the raid, it could be you have to put
manually some entry in /etc/mdadm/mdadm.conf. It is just a guess, but I
have seen this when older metadata format or no metadata in older RAID
version is used. Have look at "man mdadm.conf"

The 83 for the partition used means it is marked as linux partition. The fd
was used before to help the system know that this is linux raid partition,
so that mdadm can take over and it is OK to use it today even if mdadm
evolved and can handle the partition even if it is not marked as fd.
I would assume it was older RAID version when this was created - there is no
meta or old meta format. This is why I would try manually writing the
mdadm.conf for this partition.

You can use blkid /dev/sdb1 and use the UUID to create the entry for
example:

blkid /dev/sda1
/dev/sda1: UUID="5c88d19b-4345-d8c6-e214-edc45ed40d02"
TYPE="linux_raid_member" PARTUUID="86e010a2-01"

and the record in mdadm.conf is

ARRAY /dev/md0 metadata=0.90 UUID=5c88d19b:4345d8c6:e214edc4:5ed40d02

the metadata version 0.90 is AFAIR the old format or no metadata at all.
Check the manual

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

#230151

[Multipart message — attachments visible in raw view] — view raw

> On Wed, Dec 30, 2020, 3:08 PM deloptes <deloptes@gmail.com> wrote:
>
>> Thomas A. Anderson wrote:
>>
>> > If hardware raid (like if I bought a controller), would it be any
>> > different, if I removed the drives and just put on one another machine
>> > -- would I be able to see the data on it like a normal drive? Or would I
>> > run into the same issue??
>>
>> if you choose using hardware raid over software raid, then the management
>> of
>> the RAID depends on the controller. This means you have to use the
>> management tools provided by the manufacturer and in order to use this
>> disk on another computer, you have to make sure that the other computer has
>> also the same controller (I mean exactly the same).
>>
>
And I suggest a very first step of making sure that the firmware on the
> RAID card is up to date. I have been in situations with Dell Perc cards
> where the array was unrecoverable after media failure.
>


> Also mdadm provides monitoring and email notification, which in case of
>> hardware raid can also be done, but is more exotic or would require
>> something like SNMP.
>> It might be common in some vendor specific server hardware, but I usually
>> avoid it on no brand PC.
>>
>
> For servers there will be more powerful logging and monitoring software
> watching, so not really necessary. But you could well do the same for a
> desktop machine.
>
>>

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

#230113

[Multipart message — attachments visible in raw view] — view raw

On Ma, 29 dec 20, 21:37:01, Thomas A. Anderson wrote:
> 
> I have been using it for years, and while not a bad "thing," in
> retrospect, not sure it actually meant my critieria (eh, who knows,
> maybe it did), but now I have a more clear use case, basically to have a
> clean backup. I was using RAID1 as a "pseudo" backup, which I guess kind
> of worked, but I should use a specific backup solution.

Automatic mirroring / synchronizing is unsuitable for backups, because 
it will also sync accidental changes to files (including deletions) or 
filesystem corruptions in case of power outage or system crash (that may 
lead to corrupted files or entire directories "disappearing").

(speaking from experience here)

See also http://taobackup.com

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#230106

basti wrote: 
> On a file server in a production environment I would prefer raid 6.
> 

Making statements so cavalierly is a bad idea.

There are excellent reasons for preferring RAID 1, 10, 6, 60,
and various ZFSisms, according to expected requirements.

-dsr-

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

#230074

Hello,

On Tue, Dec 29, 2020 at 07:58:50AM +0100, Thomas A. Anderson wrote:
> I have been "using" mdadm to run software raid1 (stripping) on a file
> server i have been running.

As others have noted, RAID-1 is not striping but mirroring. I'll
assume you have used RAID-1. Showing us the content of your
/proc/mdstat file would help.

> now that I try to access data on these two original drives on
> another system, I am unable to.

The default metadata format (v1.2) for mdadm is at the beginning of
the device. If you've put a filesystem directly on the md device
then the presence of the metadata will prevent it being recognised
as a simple filesystem. What you can do is force mdadm to import it
as a degraded RAID-1.

Back in the days before GRUB understood md RAID-1 people used to
have to specifically use metadata format v1.0 or v0.9 for the device
containing /boot, in order to get metadata placed at end of device
so that GRUB was tricked into thinking it was a simple filesystem.

If you need help importing your single RAID-1 device, get it plugged
in to a system and recognised as a block device (see
/proc/partitions for a list of block devices), then show us the
output of:

# mdadm --examine /dev/whatever

where /dev/whatever is the block device for this single RAID-1
member device.

Then we'll help you get mdadm to assemble it.

Alternatively, assuming filesystem directly on md device it is also
possible to use the loop driver to create a new device that is an
offset into the md member device and then mount that as the
filesystem, but in my opinion that is more complicated and dangerous
than just getting mdadm to assemble a degraded RAID-1.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#230075

On 2020-12-29 13:10, Andy Smith wrote:
<..>
> The default metadata format (v1.2) for mdadm is at the beginning of
> the device. If you've put a filesystem directly on the md device
> then the presence of the metadata will prevent it being recognised
> as a simple filesystem. What you can do is force mdadm to import it
> as a degraded RAID-1.
<..>
I've puzzled about this. Are you supposed to have 3 disks ?
One for the OS and the other 2 for the raid1 ?

mick


-- 
Key ID    4BFEBB31

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

#230084

[Multipart message — attachments visible in raw view] — view raw

On 29.12.2020 20:32, mick crane wrote:
> On 2020-12-29 13:10, Andy Smith wrote:
> <..>
>> The default metadata format (v1.2) for mdadm is at the beginning of
>> the device. If you've put a filesystem directly on the md device
>> then the presence of the metadata will prevent it being recognised
>> as a simple filesystem. What you can do is force mdadm to import it
>> as a degraded RAID-1.
> <..>
> I've puzzled about this. Are you supposed to have 3 disks ?
> One for the OS and the other 2 for the raid1 ?
>
> mick
>
>
No, you can setup RAID1 with 2 disks, protecting both OS and user data.
It could look, for an example, like this:

          =======================================
Disk1    |  sda1  |     sda2      |    sda3    |
          =======================================
             md0         md1            md2
          =======================================
Disk2    |  sdb1  |     sdb2      |    sdb3    |
          =======================================

Where: "Disk1" and "Disk2" have identical partition layout.
        "/dev/md0" is mounted as "/boot"
        "/dev/md1" is mounted as "/"
        "/dev/md2" is mounted as "/home"

On the low-level "sda1" and "sdb1" will contain identical data and so 
the other "paired" (mirrored) partitions.
Should one of the drives fail, OS will boot from second drive.
Arrays will be in degraded state, but will resync all data when failed 
drive will be replaced with a spare.
You will have to use "mdadm" utility to perform recovery procedures 
(such as adding spare drive to array, install grub on it, etc).

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

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

#230120

Hi Mick,

On Tue, Dec 29, 2020 at 03:32:07PM +0000, mick crane wrote:
> On 2020-12-29 13:10, Andy Smith wrote:
> >The default metadata format (v1.2) for mdadm is at the beginning of
> >the device. If you've put a filesystem directly on the md device
> >then the presence of the metadata will prevent it being recognised
> >as a simple filesystem. What you can do is force mdadm to import it
> >as a degraded RAID-1.
> <..>
> I've puzzled about this. Are you supposed to have 3 disks ?
> One for the OS and the other 2 for the raid1 ?

It's unclear to me how what you have quoted relates to your
subsequent question. Can you elaborate on what the location of mdadm
metadata has to do with whether one puts the operating system on a
RAID-1 device or not?

I expect that most people using RAID put their OS into the RAID as
well. I certainly do. I don't understand your mental separation of
"OS" and "RAID-1" or why it might mandate 3 devices. It is perfectly
straightforward to put a single partition¹ on each of two devices,
RAID-1 them together and use it as root filesystem and that's it.

Probably we are just misunderstanding each other and there is a
question here that I haven't understood.

Cheers,
Andy

¹ You can just use the devices as well, no partitions, but sometimes
  weird things can happen with BIOSes that think this is an invalid
  configuration, so I wouldn't recommend it for devices you will
  boot from.

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

#230122

[Multipart message — attachments visible in raw view] — view raw

On 2020-12-30 at 08:38, Andy Smith wrote:

> Hi Mick,
> 
> On Tue, Dec 29, 2020 at 03:32:07PM +0000, mick crane wrote:
> 
>> On 2020-12-29 13:10, Andy Smith wrote:
>> 
>>> The default metadata format (v1.2) for mdadm is at the beginning
>>> of the device. If you've put a filesystem directly on the md
>>> device then the presence of the metadata will prevent it being
>>> recognised as a simple filesystem. What you can do is force mdadm
>>> to import it as a degraded RAID-1.

>> I've puzzled about this. Are you supposed to have 3 disks ? One for
>> the OS and the other 2 for the raid1 ?
> 
> It's unclear to me how what you have quoted relates to your 
> subsequent question. Can you elaborate on what the location of mdadm 
> metadata has to do with whether one puts the operating system on a 
> RAID-1 device or not?

I initially parsed this question as asking whether the metadata is
supposed to be stored on something other than the disk(s) involved in
the RAID-1.

Reading it again, it might be a reaction to the final sentence about
"force mdadm to import it"; in order to be able to do that, you need to
have the system booted to a running OS, and in order for that to happen
the OS can't be on the RAID that you're trying to import. Which would
then require at least three disks, two for the RAID-1 (of which you're
only using one, when importing) and one for the OS of the system you're
running when performing the import.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#230131

On 2020-12-30 13:38, Andy Smith wrote:
> Hi Mick,
> 
> On Tue, Dec 29, 2020 at 03:32:07PM +0000, mick crane wrote:
>> On 2020-12-29 13:10, Andy Smith wrote:
>> >The default metadata format (v1.2) for mdadm is at the beginning of
>> >the device. If you've put a filesystem directly on the md device
>> >then the presence of the metadata will prevent it being recognised
>> >as a simple filesystem. What you can do is force mdadm to import it
>> >as a degraded RAID-1.
>> <..>
>> I've puzzled about this. Are you supposed to have 3 disks ?
>> One for the OS and the other 2 for the raid1 ?
> 
> It's unclear to me how what you have quoted relates to your
> subsequent question. Can you elaborate on what the location of mdadm
> metadata has to do with whether one puts the operating system on a
> RAID-1 device or not?
> 
> I expect that most people using RAID put their OS into the RAID as
> well. I certainly do. I don't understand your mental separation of
> "OS" and "RAID-1" or why it might mandate 3 devices. It is perfectly
> straightforward to put a single partition¹ on each of two devices,
> RAID-1 them together and use it as root filesystem and that's it.
> 
> Probably we are just misunderstanding each other and there is a
> question here that I haven't understood.

I just confused myself. Initially I read somewhere that to make the raid 
first copy the OS from one disk to another.
Just struggling to get a picture of what happens, if what's on one disk 
gets copied to the other or if they are written to simultaneously.
I always understood that you can't duplicate one disk to another with 
itself being the OS.
It'll be the way the software raid does it. I should probably read more.

mick

-- 
Key ID    4BFEBB31

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

#230133

[Multipart message — attachments visible in raw view] — view raw

On Mi, 30 dec 20, 16:56:25, mick crane wrote:
> 
> I just confused myself. Initially I read somewhere that to make the raid
> first copy the OS from one disk to another.

Do you mean copy as in 'cp' or 'rsync' or similar? RAID operates at a 
lower level, typically below the filesystem (except for ZFS and btrfs, 
which integrate both).

> Just struggling to get a picture of what happens, if what's on one disk gets
> copied to the other or if they are written to simultaneously.

It should happen (more or less) simultaneously. The data is still in RAM 
so it's much faster to just write it to the other drive as well, instead 
of reading it from the first drive.

> I always understood that you can't duplicate one disk to another with itself
> being the OS.

Depends on what you understand by "duplicate".

If you mean a file-level copy, cp and/or rsync don't care whether the 
system is running or not. The problem is that files may change before 
the copy operation is completed and the resulting system is 
inconsistent[1].

As far as I know it is possible to take a "snapshot" of a running system 
with LVM, ZFS and btrfs.

> It'll be the way the software raid does it. I should probably read more.

Snapshots and RAID mirrors are different things.

[1] though this can be used to minimize downtime, e.g. by doing one 
cp/rsync pass while the system is running and a second *rsync* pass with 
the system inactive, e.g. while booted from a live system or another 
installation.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web