CentOS Linux 6.8 i386 és x86_64

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Johnny Hughes a napokban bejelentette a CentOS Linux 6.8-as verzióját i386 és x86_64 rendszerekhez. A kiadási megjegyzések dokumentum elérhető itt. Szokás szerint, a CentOS 6.8 a Red Hat által kiadott Red Hat Enterprise Linux 6.8 forrására épül. Az egyszerűbb használat érdekében a Workstation, server és minimal telepítések egy tárolóból érhetők el.

Részletek a bejelentésben.

( bra-ket | 2016. 05. 30., h – 21:24 )

Development of B-tree file system (Btrfs) has been discontinued, and Btrfs is considered deprecated.

:>

Baromi szerencsétlen a megfogalmazás, az összes RHEL-fórumon felmerült, hogy mi is ez...

Az van, hogy a RHEL6 a 6.8-as változatnál elérte azt a támogatási szintet, hogy mostantól semmilyen új feature nem kerül benne implementálásra, csak a már meglévő dolgok támogatását és hibajavításait végzik el benne. Így a RHEL6-ban btrfs-sel kapcsolatos fejlesztés sem lesz a jövőben, és mivel nem jött ki sosem a RHEL6-ban experimental-ból, így rögtön deprecated is lett.

A RHEL7-ben a btrfs-t továbbra is fejlesztik, szépen.

(Mondom ezt úgy, hogy engem speciel nem nyűgözött le a btrfs, sőt... Sosem értettem meg, hogy miért jó a hagyományos block device + LVM + fájlrendszer kombót jól elbonyolítani/máshogy csinálni csak azért, hogy máshogy legyen. Meg különben is, az XFS-t szeretem.)

Tudom, elcsépelt téma, de adattárolásra (HW RAID fölött) mi az előnye az EXT4-gyel szemben az XFS-nek? Kérdezem ezt úgy, hogy soha nem volt EXT3/EXT4 alapon adatveszésem (a fájlrendszer miatt), míg FAT16/FAT32/EXFAT/NTFS esetén egészen sokkal találkoztam (corrupted, le nem zárult fájl, crosslink, stb). Régebbi NAS-okon láttam XFS-t, de valami irtózatosan csigán írta a NAS a meta tábláját az XFS-nek (ha töröltem fájlokat, stb), igaz ez kb 6-7 éve volt...

Sakk-matt,
KaTT :)

Az, hogy jobban szeretem nem jelenti azt, hogy jobb is. :-)

Őszintén szólva sosem futottam még bele olyan esetbe, ahol a fájlrendszernek bármilyen jelentősége lett volna a működésben. Adatvesztésem mindegyikkel volt már. Úgyhogy nagyjából annyi a motivációm az XFS használatára, hogy az a default a RHEL7-ben...

Ahol sok diszk van, ott az, hogy LVM-mel fogod össze, vagy egy spéci fájlrendszerrel fogod össze, az nem nagy különbség. Csak míg az elsőt az emberek zöme vagy 20 éve használhatja kb ugyanúgy, addig a második azért jóval újabb tudomány, és ahány FS, annyiféleképpen kell megoldani.

Nem feltétlen. Már csak az inicializációs részt nézem, pl linuxnál:
sw raidhez kell particio vagy egesz diskeket mdadm + erre LVM majd fs stb. Ha csere akkor megcsinálni ismét macera.
zpoolnal meg create tank meg felsorolod a diskeket és kész ugye, cserénél detach / attach stb.

Az olyan előnyökről nem is beszélve, hogyha a pool összes diskjét kicserélted nagyobbakra akkor a pool mérete automatikusan nő. Ez a hagyományos módszernél megint csak körülményes.

Fedora 23, Thinkpad x220

Az lvm is fel van vértezve raid tudással :-P És lehet, hogy neked a raid/mirror elég, viszont fs szempontjából nem minden alá akarod ugyanazt a fs-t, mert azért van, amire az egyik, és van, amire a másik a szuboptimális... Ami meg "mindenre jó az" jelleggel lett kitalálva, az olyan, mint a svájci bicska - mindenre jó valamennyire, de szinte semmire sem optimális.

Ugy ertem miert is nem jo nekem ha mondjuk fogom ossze raidelem az osszes disket, csinalok rajta egy nagyon nagy particiot megformazom xfs-re vagy ext4 -re es jolvan, semmi LVM.

Kell -e nekem atmeretezheto /home /boot .., vagy csak a baj van vele .
Meg fogok -e halni ha nem tudok snapshotokat generalani ?

fsck el fog tartni egy darabig, es ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.