Red Hat Enterprise Linux 7 Beta

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

A Red Hat Enterprise Linux Team tegnap bejelentette, hogy elérhető tesztelésre a Fedora 19-re, valamint a 3.10-es Linux kernelre épülő Red Hat Enterprise Linux 7 bétája. A vállalati Linux disztribúció egyik érdekessége, hogy alapértelmezett adatbázis-szerverként MariaDB-t szállít.

Részletek a bejelentésben. Kiadási megjegyzések itt. Az ISO képfájlok megtalálhatók a Red Hat publikus FTP szerverén.

( insight | 2013. 12. 12., cs – 18:12 )

A MariaDB szerintem várható volt, de érdekes, hogy XFS lett a default file rendszer.

abbol a szempontbol ertheto a dontes, hogy milyen elonyei vannak. par eve csinaltam nehany tesztet egy fiber-disk-es storage-on (ezt csak azert emlitem kulon, hogy nem annyira barkacs cucc volt) akkor meg csak ext3-al es jfs-el szemben allt az xfs, ext4 akkor meg nem merult fel komolyan. az ext3 es az xfs kozott akkor volt 10-12% koruli kulobseg az xfs javara. jfs 3-4%-al volt lassabb viszont cserebe meg instabil is volt. 3-4gb es afolott en az xfs-t favorizalom foleg az fsck, atmeretezes, teljesitmeny vonal alapjan. a meretbol is latszik, hogy itt nem nagyipari felhasznalasrol van szo. oda az aktualis ajanlas szerinti fs kerul.

mindenesetre kivancsi leszek majd a tapasztalatokra.

sebessegben. az ext* filerendszernel egy 2tb -> 4tb online resize sokkal tovabb tartott mint xfs-nel. pontos idokre nem emlekszek mar, az eredmeny maradt meg. az ext2 offline resize meg nem alternativa (eszmeletlenul lassu a meretcsokkentes), legfeljebb ha nincs hova kimenteni az adatokat. anelkul meg ugysem csinalnek shrink-et.
mindazonaltal abban igazad van hogy online csokkenteni egyik sem tud.

Azért az megvan, hogy a csökkentés elvileg sem tud nagyon gyors lenni? Valahogy el kell takarítani az adatokat a block device végéről.

Az ext* online resize meg azért lassú, mert gondolom default bytes/inode beállítással lett létrehozva a fájlrendszer, 2TB-nál kb 100M inode-nak létre kell hozni az adatszerkezetet. Mivel tudom, hogy ennyi fájl gyakorlatban sosem megy rá, mondjuk inkább max 1M körül lesz, ezért bőven lejjebb lehet venni és akkor máris nem olyan lassú.
---
Régóta vágyok én, az androidok mezonkincsére már!

a csokkentes is lehetne gyors, ha elotte mondjuk "defrag"-olod, tehat atpakolod a tenyleges adatblokkokat. ezt lehetne akar online is, ezek utan lehetne gyors is az atmeretezes. de nem az, igy felejtos.

nekem nagyjabol mindegy mitol lassu, ha a vegeredmeny azt adja, hogy egy lassu atmeretezesi procedurat aggodhatok vegig (bar negativ vegeredmeny meg nem volt) vagy szinte azonnal kapom a megnovelt meretet.
nem lennek benne olyan biztos, hogy nem megy ra ennyi file. van ahol a default bytes/inode is keves/pazarlo. megtortenhet, ha ez mondjuk egy x1000 useres maildir formatumban tarolo mailszerver alatt lenne. akkor elolfordulhat a sok millio file. az xfs ebben az esetben is jobban teljesitett.

mivel meg mindig a multban tapasztaltakra hivatkozok, ugy erzem ideje megismetelni a tesztet a jelen kernel/sw kornyezeteben is. kivancsi leszek mit mutat majd.

( zotya62 v | 2013. 12. 18., sze – 12:22 )

Hogy lehet meglevő Redhat fiókkal letölteni?