EXT4 -> BTRFS migráció

Naplózó filerendszerek (journaling)

Otthona konfigom Fedora31 külön /boot, /boot/efi, /, és /home partíciókkal EXT4-ekkel.
BTRFS-ről pedig azt olvastam, még korábban, hogy elég lesz 1 BTRFS partíció mindenre és ez - the way it  meant to be played.
OK.
Majd egy évvel később újratelepítéssel frissítem a Fedora 33-at.
EXT4 esetén formáznám a /boot és / partíciókat, de mi a scenario BTRFSsel?
 

( gentoojedi | 2020. 10. 17., szo – 21:14 )

Én nem igazán értem a kérdést.

Miért akarsz btrfst? Ext4-en és az összes többi linuxos fájlrendszer alkalmas arra célra, miszerint  egyetlen partición lehet minden az efi meghajtót kivéve. Mert az bizony fat.

BTRFS-nek van egy olyan előnye többek között, hogy ha swapfilet használsz tudja változtatni a méretét. Tehát ha mondjuk 16GB swapot szeretnél, akkor nem tart fent egy 16 GB-os swapfájlt állandó mérettel, hanam használattól függően növeli, ha pont nincs szükség rá, akkor a mérete közel nulla Byte. Igaz ez nem tudom mennyire kiforrott, azt hiszem legalább 5.0-ás kernel kell hozzá. De mintha fedorán a btrfs szopó lenne.

Szóval, ha csak amiatt szeretnél btrfst, amit irtál felejtsd el, legalábbis fedorán, mondom úgy, hogy én már évek óta btrfst használok - igaz gentoon.

> összes többi linuxos fájlrendszer alkalmas arra célra, miszerint  egyetlen partición lehet minden

Az, hogy alkalmas, nem jelenti, hogy célszerű, jó. A /usr, /var megérdemel külön partíciót. A /home meg akár külön diszket.

> van egy olyan előnye többek között, hogy ha swapfilet használsz tudja változtatni a méretét

Ha jól emlékszem, ezt a win3.1 is tudta. De a win95 biztos, ez volt a default. És ez volt az egyik dolog, amit (újra)telepítés után célszerű volt átállítani fix méretre, mert észrevehető gyorsulást okozott. Amúgy a linux swap partíció nem csak swap-hoz jó (és gyorsabb a swap-fájlhoz képest), hanem hibernáláshoz is kell. Ezt is tudja a btrfs?

> Várom azok jelentkezését, akiknél ez most így van.

:) Miért? Nálad hogy van?

Nos, nem lesz sok jelentkező (rajtam kívül). Pl. mert már ez OFF-topic.

Vannak (sokan) a win+linux dualboot-osok, akik örülnek, ha az, 1-1 partícióval működik. Vannak (sokan) disztrópróbálgatók, akiknél esetleg egy linux install állandó, és a csak kipróbálásra telepített, hetente változó disztrókhoz nyilván nem csinálják így.

Aki mar szivott amiatt, hogy megtelt a /var particioja egy elszabadult logfajl miatt, vagy megtelt egy alulmeretezett /root a sokadik frissites utan, vagy aki a konnyebb reinstall miatt (is) tartja  a /home-ot, az szereti kulon kezeltetni ezeket.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Csak úgy kérdezem. Hogy ha van egy 1 TB-s HDD-d. 

Mikor van nagyobb esélye, hogy elfogy a szabad hely?

1. Egy partíció az egész. A szabad hely kb. 950 GB

2. Csinálsz egy 20 GB-s partíciót a /var-nak, amin a szabad hely 15 GB.

 

Egy egy felhasználós, egy HDD-s gépen a szétpartícionálásnak - a magad szívatásán kívül - kb. szerintem semmi értelme.  Sosem használtam külön /home-t. A külön swap partíciót is megszüntettem pár éve. Ilyen log fájl miatti hiba azt hiszem egyszer volt úgy tíz éve. Beléptem root-ként töröltem a felesleges fájlokat, újraindítottam, és kész is voltam. Szerveren a több partícióra bontás biztos nagyon hasznos, de egy otthoni gépen? Persze ha valaki ettől érzi jobban magát. Tőlem tegye. 

Single useres rendszernél tényleg mindegy, mehet minden a cékerttőspontvisszaper meghajtóra. Egyébként meg egy darab diszk esetén ugye van egy pv-d, egy vg-d, amiből vagy egy rootlv-t csinálsz (vagy hagyod az egész LVM-et, és cékettőspontvisszaper stílusban oldod meg - egyben), vagy szétválasztod ez egyes területeket, és különrakod a /-t, a /var-t (esetleg a /var/log-ot), a /home-ot, meg mondjuk a /opt-ot (és nem pakolod tele indulásnál a logikai kötetekkel a diszket, hiszen induláskor kevésbé szokott "tiszta" lenni, hogy hova, mennyi hely kell majd.
ha meg disztrót váltanál/cserélnél, akkor naaagyon jól tud jönni, hogy a /home-ot az OS-terület teljes formázása/lesíkálása nem érinti... (Na ezért is van nálam Windows-on is a profil a cékettőspontvisszaper helyett egy másik fizikai diszken...)

Szerverkörnyezetben a felcsatolásonként adható noexec opció miatt is szeretjük szétszedni + quota + ...
Desktop környezetben a /home -ot mindenképpen érdemes külön tenni. Így ha újratelepítesz, akkor a user adatok nem vesznek el.

A Btrfs az egy partíció előnyeit és a sok partíció előnyeit is hozza.
Fizikailag elég egy partíció, de logikailag több subvolume-ra tudod bontani.

Az egy partíció előnye, hogy az összes szabad hely rendelkezésre áll minden rész számára.
A több partíció előnye, hogy egy-egy adott résznek meg tudod mondani, hogy maximálisan mennyire növekedhessen. Pl. a lognak adsz max. 20 GB-ot, így nem lesz az, hogy a log megeszi az összes helyet a fontosabb adatok elől.
A Btrfs-sel egy partíciód lehet, tetszőlegesen sok subvolume-mal, amikre kedved szerinti korlátokat adhatsz meg.
További előnyei, hogy a subvolume-ok könnyen snapshotolhatók, cserélgethetők.

Egy egy felhasználós, egy HDD-s gépen a szétpartícionálásnak - a magad szívatásán kívül - kb. szerintem semmi értelme. 

Sosem használtam külön /home-t.

Ezt a két mondatot pláne együtt gondold újra. Pont azért használok külön partición, azaz most már külön meghajtón homeot, pont azért nehogy megszívassam magam.

Miért is?

Az adataimat másik HDD-n tárolom. Részben Win miatt. Azaz nem tárolok adatot rendszerpartíción -> /home-n se. Mint ahogy c:-n se.  Azaz ha újraformázom a /-t partíciót a /home-mal együtt, csak a beállítok azon része veszik el, amit nem mentek külön. Értelemszerűen azokért nem kár. Azaz majdnem ugyanazt csináljuk egy különbséggel. -> Szerintem az adatok mentése és a /home (beállítások) mentése két külön dolog. Nem kéne összekeverni a kettőt. Nagyon sok program szemetel a /home-ba, én egy újratelepítéskor örömmel szabadulok meg olyankor tőlük. 

Hetente 1-2x mentek külső HDD-re. A /home tartalmát nem szeretném menteni, csak az adataimat. A külön /home se rossz, de szerintem jobb így.

Miért is?

Jó akkor egyezzünk meg abban, hogy használattól függ.

Neked szívás a külön home, nekem meg a nem külön home lenne az.

Én a nagyon fontos adataimat a szerveremen tárolom és egy plusz példányt a home könyvtáron belül, ami alatt a fájlrendszer raid1en van.

Gondolom Te azért a windowson tárolsz mindent, mert a linuxod egy hobbi rendszer. Ezt abból vonom le, hogy újratelepítéssel oldasz meg dolgokat. Hiba. Úgy meg tényleg szopni lehet vele, ha a rendszered jellegéből (instabil disztró) vagy nem kellő hozzáértésből valami elcsesződik. A hozzászólásodból az jön le, hogy nem igazán értesz linuxhoz, igy viszont kár álláspontot foglalnod, mert Nálad van a hiba.

Nagyon sok program szemetel a /home-ba

Juj! Te ha tudnád nekem mennyit szemetel a gentoom, sikítanál szerintem. Apámnak voltak disznói, nem undorodom a ganajozástól.

A homeot is lehet ganajozni, akár manuáisan, sőt be lehet állítani ízlés szerint a homeon belül alkönyvtárakat, amit akár ramba csatol fel a rendszer és leállításkor elvész tartlma. Locsemege szeret ilyen ínyencségeket.

 Jó akkor egyezzünk meg abban, hogy használattól függ.

Ebben egyet értünk.

Egy kis statisztika:

A teljes /home nálam 4,4 GB.

Ebből

2,9 .cache

0,9 .wine

0,4 .config (ebből 0,3 chrome beállítás -> használom a syncet)

0,16 egyéb rejtett fájl (a fele firefox beállítás -> használom a syncet)

0,13 Saját dok - online is elérhető

Ebből a 4,4 GB-ból kb. 0,1 GB az a beállítás, amire egy esetleges újratelepítéskor szükségem lehet (Többnyire nincs). Ezért rakjam külön a /home-t és őrizgessek több mint 4 GB ballasztot? 

Mondtam már te összekevered az adatok mentését a beállítások mentésével. Az adataimról 4 biztonsági mentésem van. A /home-ról egy sincs. 

Gondolom Te azért a windowson tárolsz mindent, mert a linuxod egy hobbi rendszer.

Erre csak annyit, hogy nemrég cseréltem el a windowsos tabletemen a win-t linuxra. Azért kíváncsi lennék, hányan használnak tableten linuxot. 

Mondtam már te összekevered az adatok mentését a beállítások mentésével.

Nem összekeverem, hanem alapból a /home/user mappában vannak alapesetben is a beállításokon felül a felhasználó adatai, amit alapesetben ott is tárolnak, mint ahogy Windowsnál az User mappa (Asztal, Dokumentumok, Képek, Zene, Videók stb)

Legfeljebb Te nem úgy tárolod, meg még néhányan.

Erre csak annyit, hogy nemrég cseréltem el a windowsos tabletemen a win-t linuxra. Azért kíváncsi lennék, hányan használnak tableten linuxot. 

Nocsak. Statot nem tudok, de nekem pl tabletem sincs. Gyűlölöm az olyan eszközöket, amihez nincs hardveres billentyűzet. Az okostelefont is a legminimálisabb dolgokra használom.

Ha csak böngészés meg Googledocs a cél, (ahogy az a felhasznált területek eloszlásából nagyjából kiderült) akkor valóban nem sokat veszít, ha a $HOME könyvtárát legyakja egy újratelepítés. Szerintem innentől kezdve meg simán használhatna tmpfs-t a /home alá pam_mkhomedir-rel ügyesen nyakonöntve - még tán gyorsabb is lenne az egész :-D

Jelen (majndem így). A rootvg szét van szedve / /var /var/log részekre, van swap, tmpfs, van datavg a /srv /opt /home minden egyéb részére, illetve szükség szerint még néhány további szeparáció - a gép/vm funkciójától függően (A legújabb vm-ek már 3 diszkkel indulnak, egy booteszköz, egy a rootvg alatt, egy a datavg alatt. A vg-k nem partícióra, hanem a teljes diszkre kerülnek (így a partíciók mókolása kimarad, ha kell bárhol diszket/területet növelni).

Azt irja, hogy nem a systemd az oka.

Azt irja vagy nem irja, nekem gentoon openrcvel működött. Aztán én balfasz a laptopomon áttértem systemd-re, aztán nyekk. Visszatértem, de nem emiatt, hanem alapból megvagyok systemd nélkül. Mellesleg gentoon a systemd és az SELinux profiluk confliktolják egymást.

hanem hibernáláshoz is kell. Ezt is tudja a btrfs?

Azt lehet, hogy nem, de ssd-nél nem szokás hibernálni, mert nem lesz észrevehető különbség a rendes indítás és a hibernált állapotból visszatöltött rendszer boot ideje között. Ettől függetlenül lehetne rá igény, ha valaki a másik előnye miatt használja, miszerint szereti onnan folytatja a munkát, ahol abbahagyta és nem akar minden indításkor 93 alkalmazást újra megnyitni. Erre viszont vannak alternatív megoldások. Linuxon meg pláne.

> Erre viszont vannak alternatív megoldások. Linuxon meg pláne.

Van, de mindegyik alternativanak vannak hatranyai, ami miatt csak MAJDNEM olyan jo, mint a hibernalasbol visszatoltott statusz. Meg mindig egy csomo elonye van hibernalasnak.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( tompos v | 2020. 10. 17., szo – 21:30 )

Valoban lehet 1 particio es subvolume-okat hozhatsz letre. Annak, aminek akarsz es annyit, amennyit akarsz.

Akkor formázni subvolume-nként lehet, vagy hagyományosan partíciónként?

 

[UPDATE:]

A Fedora 33 Auto disk partícionáló telepítője azt csinálja, hogy lesz egy /boot/efi EXT4, /boot EXT4 és a maradék / BTRFS.
Ami újratelepítésnél megintcsak kérdéses lesz, talán kipróbálom a / külön és ( /home + swap ) szintén külön BTRFSsel.
Talán egy VMre felteszem előtte.

Nincs formázás, a subvolume nem külön fájlrendszer, hanem ugyanazon a fájlrendszerben egy új tree.

A directory's keys simply list all of the files contained within the directory, twice. The first list consists of a sequence of DIR_ITEM keys, ordered by the hash of the item's name (this is stored in the offset of the key). The second list consists of a sequence of DIR_INDEX keys, ordered by the "natural" order of the directory (typically in creation order). Both key types store the same structure, which references the key of this object's inode, and holds the full name of the object within this directory. The referenced key will be either of type INODE_ITEM, in which case it is an ordinary POSIX filesystem object and can be looked up in this tree; or it will be of type ROOT_ITEM, in which case it's a subvolume, and the subvolume objectid should be looked up in the tree of tree roots to find the corresponding FS tree.
(https://btrfs.wiki.kernel.org/index.php/Trees#Directories_and_subvolumes)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Leformázod a partíciót. Ezzel létrejön a BTRFS.

Subvolumet ezek után annyit hozol létre menet közben, amennyit akarsz.

btrfs subvolume create ...
btrfs subvolume delete ...

Ha a gyökér partíció is egy subvolume, akkor ha újat akarsz akkor csak egyszerűen eldobod a régi subvolume-t.
Formázni tehát többet már nem formázod a /dev/sdaX eszközt, csak create és delete.

De a Google a te barátod is gondolom:
  https://btrfs.wiki.kernel.org/index.php/Getting_started#Basic_Filesystem_Commands
  https://btrfs.wiki.kernel.org/index.php/SysadminGuide

Még csak formázni sem kell. Létrehozza a partíciókat, megmondja melyik milyen szerepben legyen, a telepítő meg intézi a többit, csak el kell fogadni a default opciókat, Fedora 33 óta a btrfs a default, amire formáz. Fedorán még nem használtam btrfs-t, csak Archon, még régebben, mikor a swap fájlt sem támogatta bug miatt, de nekem ennek ellenére is tetszett, egy elég stabil fájlrendszernek tűnt, nem volt vele problémám, adatvesztésem. Akkoriban kifejezetten azért tettem fel, mert még lassú HDD-t használtam, és annak kellett a leválasztás nélküli online defrag, amit csak a btrfs tudott akkoriban. De az ext4-et jobban preferálom, ha SSD-ről van szó, és nem kellenek a btrfs extra feature-ei, mert akkor az ext4 gyorsabb, egyszerűbb, kisebb az overheadje, több disztró által támogatott out of the box, átlag desktop felhasználásra elég az is. De ennek ellenére a btrfs-sel sincs baj, persze meredeknek tartom, hogy defaultként rátolják mindenkire Fed Dórikáék.

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

meredeknek tartom, hogy defaultként rátolják mindenkire Fed Dórikáék.

De miért? Süsüben lassan egy évtizede default, mind az open ágon, mind az enterspájz verzióban...

Amúgy nekem már volt btrfs adatvesztésem: több diszkes sima "raid0" (eredetileg egy sima partíciónak indult, csak túlnőtte magát :) ), egyik disk bad sectoros, a btrfs szépen megmondta, hogy melyik fájlok a rosszak (checksum, hasznos feature ;) ), azokat töröltem. Utána eszköz csere, mint kiderült egy másik hibás diszkre (fasza...), és volt egy áramszünet... itt már valamelyik FS tree node-al is gond volt, de ro-ban még engedte felcsatolni. Mivel kb. eldobható adat volt, kb. kíváncsiságból nekiestem a btrfs fsck összes experimental (!!!) ellenőrzőjével (közepén újabb áramszünet...), így annyira megborult, hogy már csak a btrfs fsck akármilyen rescue módja (ami nem nyúl az FS-hez, csak kimenti a fájlokat egy új helyre) maradt (ami szépen kiszedte a fájlokat, de a hard linkeket újra másolta volna, ami miatt nagyságrendileg 60x annyi terület kellett volna hozzá), úgyhogy inkább lelőttem és eltettem a lemezeket, aztán újra előállítottam az adathalmazt...

Szóval aki a btrfs miatt veszít adatot, az NAGYON veszíteni akart adatot :)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Így van, még annyival egészíteném ki, hogy a subvolume-ok létrehozása után az fstab-ba meg kell adni, hogy melyik subvolume-ot hová kívánod csatolni.

Pl.

UUID=b162b995-9aa8-493b-9a92-6a2d6484246e /      btrfs  noatime,nodiratime,subvol=@     0 1
UUID=b162b995-9aa8-493b-9a92-6a2d6484246e /home  btrfs  noatime,nodiratime,subvol=@home 0 2

A @ és a @home a subvolume-ok nevei nálam, a b162b995-9aa8-493b-9a92-6a2d6484246e UUID-jű partíción.

( Adamyno | 2020. 10. 19., h – 15:26 )

Btrfs-ben nekem a snapshot feature tetszik.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...