[Megoldva] Linux RAID1: lehet egy HDD-vel nekifutni?

Linux-kezdő

A címben nem tudtam az egész problémát vázolni, itt kifejtem. Az a kérdésem, lehet-e eleve féllábú RAID1-re, tehát egyetlen diszkre telepíteni, amely egy olyan RAID1 tagja, amelyiknek hiányzik a másik diskje, majd telepítést követően berakni a másik disk-et, s azt várni tőle, hogy szinkronizálja fel a későbbi lemezre a kezdetektől bent lévő lemez tartalmát.

Azért szeretném így, mert két SSD-ből az egyik a régi gépem oprendszere, de a file-ok másolását követően ez az SSD lenne a RAID1 másik diskje.

( mauzi v | 2021. 10. 12., k – 22:31 )

Lehet. A hiányzó komponens helyére írd, hogy "missing".

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda missing

Ha így létrehozom a tömböt, akkor a későbbiekben lehet UUID-dal hivatkozni? Ugye az a para, hogy senki sem garantálja, hogy mindig ugyanaz a device lesz az sda, arról nem is beszélve, ha itt a piros, hol a pirost játszok a SATA kábelekkel.

Fogok doksit olvasni, megígérem, de felmerült néhány kérdés bennem. Mondjuk megadom neki, hogy az egyik disk hiányzik. Amikor beraktam a gépbe, hogyan tudom elmesélni, hogy ő a második disk, s most már nem missing?

További kérdésem, hogy preparálni kell-e a másik device-t, vagy mehet be a gépbe csupaszon, 0-kkal végigírva, s szektorosan megcsinálja a szinkronizálást. Nekem az volna logikus, hogy nem kell formázni, de a pontosan azonos méret miatt egy picivel kisebb partíció célszerű, s akkor /dev/sda1 /dev/sdb1 lesznek például az eszközök.

Jó, tudom, rtfm, fogok olvasni, de ha van pár perced, jólesne néhány gondolat erről. Most rakok össze új gépet - a jelenlegi 13 éves múlt -, s mind a HDD-t, mind az SSD-t RAID1-be rakom, hogy kisebb eséllyel bukjak adatot, legalább is háttértár pusztulásból adódóan.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amikor berakod a másikat, akkor:

mdadm --manage /dev/md0 --add /dev/sdb1
 

Metadata miatt nem okoz problémát, hogy melyik kábelre mikor mit dugsz, nem fogsz vele rosszat csinálni. 

mdadm --detail --scan

vagy

mdadm --examine --scan

megmutatja a tömböket. Ha akarod, akkor ezeknek a kimenetét lehet a /etc/mdadm.conf -ba tenni.

Nem kell előre preparálni a másik eszközt, majd megoldja magának amikor rebuildet csinálja.

https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Köszönöm. Ha jól sejtem, a /dev/md0-ra úgy legegyszerűbb több fs-t feltenni, ha lvm-et használok. Vagy btrfs-t, de ez utóbbihoz semmi kedvem. Valahogy azt eléggé butaságnak érzem, ha egy tömb egyetlen diskjén lenne az md0, md1, md2, md3 (egyik példánya), mert akkor disk halál esetén egyesével kell az összeset adminisztrálni. Ezért gondolnám, hogy legyen egyetlen md0, amit odaadnék az lvm-nek, mint fizikai kötetet, s egyben vg-t is, aztán abban hoznék létre több lv-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

en nem hasznalom igy, de:

/boot/grub/i386-pc$ ls -l lvm* md*
-rw-r--r-- 1 root root 6884 Feb  9  2021 lvm.mod
-rw-r--r-- 1 root root 2052 Feb  9  2021 mda_text.mod
-rw-r--r-- 1 root root 2020 Feb  9  2021 mdraid09_be.mod
-rw-r--r-- 1 root root 1944 Feb  9  2021 mdraid09.mod
-rw-r--r-- 1 root root 1944 Feb  9  2021 mdraid1x.mod
 

persze ha regi lilo/grub-od van akkor nincs ilyen

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Raynes | 2021. 10. 13., sze – 05:23 )

Ha ilyen kívánalmaid vannak, ezt a ZFS is tudja.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Erőforrás-megszorítás nem volt említve. Igen, kicsit több hw kell neki, de rugalmasabb megoldás, mint a RAID, és van néhány extra szolgáltatása is. Csak ezért hoztam fel.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Engem nem kell meggyőzni, én abszolút, minimalista, anti-raid, anti-bonyolításmentes, ext4-párti vagyok, és ha kéne is hasonló megoldás ZFS-hez, én btrfs-t használnék helyette, de azt kell látni, hogy az ZFS nem ok nélkül népszerű azoknál, akik körében népszerű. Nem azt mondom, hogy kötelező használni, de egy megfontolást megér, hogy az alternatívák között mérlegelje valaki. Nem véletlen, hogy sok NAS-os megoldás is default használja, meg a FreeBSD, Solaris-klónok (Illumnos és társai), stb..

Az se kizáró ok, hogy desktop gép, ha nem túl ergya, 32 bites, meg ilyen 1-2 giga RAM-os Celerongy és társai vicc kategória, akkor mai modern hardvernek nem tétel, akkor se, ha egy 10 évvel ezelőtti gép. Ilyen C2D, Phenom, stb. szintjén sem vészes, egy Core i akárhány genes proci meg meg se érzi, ha van elég RAM a gépben, de az amúgy is ajánlott ma már, mármint a 4 giga abszolút minimum desktopra, főleg, ha valaki ragaszkodik mainstream bloat DE-khez, Chrome-alapú böngésőkhöz, de a 8 giga még ajánlottabb.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Mivel a jelenlegi gépem idősebb 13 évesnél, egy új configot rakok össze. Ryzen 7 5700G, 32 GiB RAM, MSI B550M-A PRO alaplap, nincs dedikált VGA, a CPU-ban lévőt használom, 2 x 2 TB HDD RAID1-ben /home és /var-nak, 2 x 500 GB SSD szintén RAID1-ben /-nek és /boot-nak. Az alaplapin kívül teszek bele még egy 1 Gb/s-os hálókártyát, meg hátlemez USB csatlakozókra kihozom az összes USB 2.0 és USB 3-as portot. Vettem bele 600 W-os Zalman tápot - ne kérdezd, minek, mert az egész gép nem fog többet enni 200 W-nál akkor sem, ha mind a 8 magot 100 %-ra hajtom.

A ZFS nem zárt forrású? Amúgy szerintem nem ilyen pici rendszerhez való a ZFS, illetve efféle célra akkor már ott lenne a btrfs. Viszont eldöntöttem, hogy md-vel RAID1, abban LVM, abban ext4 lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát ha már felmerülne komolyabban a btrfs, akkor már inkább zfs-re mennék (btrfs: 4-5 éve még nem voltam impresszálva).

Te mondjuk Fedora-t használsz, abban nem tudom, milyen támogatása van a ZFS-nek, de az viszont biztos és fontos, hogy a ZFS-t meg kell érteni és meg kell tanulni. Az szerintem nem olyan, hogy felraksz egy RAID1-re egy LVM-et és zamek, bár nagyon hasonló.

Azt is mondják, erőforrás (memória) igényes, FreeBSD-n pl. az 'vfs.zfs.arc_max' változóval remekül kordában lehet tartani. Ahogy látom, linuxon ez az '/etc/modprobe.d/zfs.conf' -ban a 'zfs_arc_max' opció.

jó is az ext4... Kivéve ha egy kernelfrissítés agyon nem csapja a teljesítményét... Oké, kifejezetten i/o igényes alkalmazás (sok kicsi írás), de a kernelcsere után a korábbi  2-5% iowait felment konstans 10-15%-ra, nagyobb terhelésnél meg bőven 50% fölé(!). Príma volt, mit ne mondjak... (Ubuntu 16.04 - 18.04 frissítés volt - vissza kellett állni a 16.04-ben használt kernelre...)

Őszintén szólva nem aggódom. Kb. az az igénybevétel, hogy betöltse a fejlesztői környezetet meg egy mikrokontroller forráskódját. Szerintem, ha egy kis kínai diktálná ilyenkor a forráskódot, a másik meg begépelné, még az is megfelelő betöltési sebesség volna. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2021. 11. 01., h – 23:47 )

Szerkesztve: 2021. 11. 01., h – 23:52

Ez most egy másik gép - egyébként az, amelyikről az újra költöztem -, kialakítottam egy ilyen layout-ot, persze privacy okokból előbb szektorosan mindkét HDD-t 0-kkal írtam tele.

sda1 - ext4 /boot 2 GiB
sda2 - raid1 kb. 500 GB - 2 * 2 GiB
free - 2 GiB szabadon hagyva a végén

Utána

sfdisk -d /dev/sda | sfdisk /dev/sdb

majd sdb1-et töröltem. Ezt követően mdadm-mal összeraktam a raid1 tömböt, pvcreate, vgcreate, lvcreate parancsokkal létrehoztam az lvm lv-ket, majd mkswap és mkfs.ext4-gyel a filerendszereket. Eddig működött, majd elindítottam a Fedora 35 telepítőjét, s azzal kezdte, hogy az sda2 és sdb2 uuid-ja azonos, így szóba sem áll velem.

Viszont, ha jól sejtem, nem a partíciónak, hanem a benne található filerendszernek, ebben az esetben a raid-nek van uuid-je. Gyanítom, ha nem lenne azonos, nem találná meg az md alrendszere az összetartozó eszközöket. Szóval az uuid-ekhez nem nyúltam, gondoltam, átverem a telepítőt, s lehúztam sdb SATA kábelét. Akkor persze az lett a baja, hogy ez egy fél lábú raid. Mondjuk fogalmam sincs, mi köze hozzá. A koncepció nyilván az volt, hogy majd visszaszinkronizálom telepítés után.

Miután ebbe belebuktam, elindítottam a telepítőt egy HDD-vel, majd miután túlesett az uuid-ek ellenőrzésén, visszadugtam sdb SATA kábelét, aztán pedig

mdadm --manage /dev/md0 --re-add /dev/sdb2

következett. Megcsinálta, persze a Fedora telepítőnek nem tudtam megmondani, hogy a kész layout-ra telepítsen. Windowsosodik ez is. :(( Mondtam neki, hogy akkor törölje a raid alól az lvm-et, majd létrehozattam volna vele újra a GUI-ról. Elvileg hagyta, de amikor végre kellett volna hajtania a régi lvm layout törlését, megpusztult ez a Python-ban írt fantasztikus telepítő.

Most megpróbálhatom az md0 belsejének elejét törölni dd-vel, majd átverni a telepítőt féllábú raid-del, majd lvm-et beletenni a telepítőből, vagy már a raid1-et is onnan. De miért nem engedi kész layout-ra telepíteni az oprendszert?

Igaz az a vélelmezésem, hogy sda2 és sdb2 uuid-ja azonos kell legyen, s az mdadm --create hozza létre? Vagy van valamiféle uuid, ami tényleg a partícióhoz tartozik, s nem ahhoz, ami a partícióban van?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

mdadm a device vegen tarolja a raid cuccokat. van uuidja az fs-nek (ezt pl a blkid parancsbol latod). van uuidja a raidnak (mdX), es "ez van" a devicen is (ebbol tudja hogy ki tartozik egybe):

# mdadm -D /dev/md126 |grep UUID
              UUID : cdf2592d:cee6590b:4b293102:23ba2675
# mdadm -E /dev/sda1 |grep UUID
           UUID : cdf2592d:cee6590b:4b293102:23ba2675
# mdadm -E /dev/sdb1 |grep UUID
           UUID : cdf2592d:cee6590b:4b293102:23ba2675

mdadm --zero-superblock torol minden raidhez tartozo "metaadatot" a backend devicerol. ha mdX-en volt fs, akkor az "latszik" a sdXX-en is. azt a wipefs-el tudod lepusztitani.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ha mdX-en volt fs, akkor az "latszik" a sdXX-en is

Ha jól értem, akkor ebbe futottam bele. Na jó, de a Fedora telepítő ne legyen már annyira ostoba, hogy azt gondolja, ez klónozott disk két fs-sel, de azonos uuid-dal. 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jól emlékszel, tud. Az a bajom vele, hogy a GUI mindig szerényebb lehetőségeket kínál, mint amit CLI-ben meg tudnék csinálni. Például partícionálásnál az ending sector esetében megadható a -2G, ami a default vége előtt 2 GiB-tal lesz. A layout-ot szeretem CLI-n kialakítani, de sajnos nem eszi meg. Marad a telepítőből szerencsétlenkedés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE