OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Ahojte.
Chcem sa vas spytat aky filesystem by ste zvolili na server, ktory ma 3x 1.2 TB disky (nebudu v raide, ale pripajane samostane, kazdy do svojho adresara, cize ziadne LVM), budu obsahovat 50-300 MB fajle ktore bude publikovane cez apaca.
Bolo mi povedane, ze ext3 nie je na taketo nieco vhodne (rychlost, naroky na CPU). Mam vraj skusit JFS.
mate niekto nejake skusenosti s tymto? Nemozem si dovolit o tie data prist ani keby krompace z neba padali.
Je pouzitie JFS naozaj bezpecne? Cital som rozne topici o JFS, XFS aj ReiserFS ale:
XFS - velka cache. Pri pade ostavaju zapisovane fajle na "0".
ReiserFS - jeho prava sila je len na filesysteme s velkym mnozstvom malych suborov... .
JFS - zda sa, ze nema chyby. Ale vsetky nazory okolo neho boli od ludi co ho maju na laptope. Je rovnako dobry aj pre server???
Dakujem za pripadne odpovede.
Ok.
Spravil som si taky testik.
#mkfs.xfs /dev/sda10 (/home)
#mount /home; cd /home
#dd if=/dev/zero of=subor.dev bs=1024 count=8124000 (tento prikaz zacal vytvarat subor o velkosti cca 8 GB).
#ls -lah
........................ 2.2GB subor.dev
(pri 2.2vytvorenych gigabajtoch som pocitac pocas procesu "dd" natvrdo zresetoval).
Vysledok po restarte?
#ls -lah
........................... 0 subor.dev
Pri JFS a aj ext3 ostala zachovana posledna zapisana informacia, cize:
#ls -lah
........................... 2.2GB subor.dev
Spravil som v tomto svojom "improvizovanom" testiku v niecom chybu ja? Ukrivdil som XFS filesystemu?
Prosim zhodnodte kde som sa kopol...?
Dakujem.
Asi je vsechno v poradku XFS tak proste funguje, ale resis zbytecnosti . Pokud mas server na UPS tak se nemas ceho bat a i kdyby se stalo ze server z nejakeho duvodu spadne, tak bude lepsi mit soubory nulove delky u kterych je hned jasne, ze je musis obnovit ze zalohy, pripadne znovu nahrat, nez nechat na disku soubory s nekonzistetnim obsahem a zjistit to treba az za mesic.
ps. To ze ma na ext3 a jfs soubor 2.2GB jeste neznamena ze v nem skutecne je 2.2GB dat a uz vubec se nemuzes spolehnout na spravnost jeho obsahu. A stejne co by jsi s takovym souborem chtel po restartu delat?
Pouzil som cistu distro Debiana lennyho. Neviem aka presne verzia jadra tam teraz je. 2.6.28? Mozno trepem.
Ale mate pravdu v tom, ze lepsie je mat subor s nulovou velkostou ako subor plny bludov.
Len sa trochu bojim -- co ak bude v zapise prave nejaky MySQL DB fajl. Nehrozi mi, ze sa mi "znuluje" ??? Keby sa mi posrala databaza, to by ma sralo este viac.
Ale prave som si precital:
http://www.root.cz/clanky/velky-test-osmi-linuxovych-souborovych-systemu/ a zrejme ostanem pri ext3 s moznostou neskorsieho prechodu na ext4.
Hmm?
Z mé osobní zkušenosti: XFS rychlé, ale jak bylo již výše zmiňováno+na některých serverech se mi sám rozkládal(značkové servery -některé Fujitsu-Siemens a HP, ale asi mu nějak nesedly). Na nejnovějších jádrech jsem ho už nezkoušel. Naposled snad 2.6.18. Teď všude používám ext3 - rychlost ujde, zatím mě nezradila a co se týče třeba zmiňované databáze mysql, stalo se, že databázovému serveru padla i UPSka či spadlo jádro, datazáze pak šla opravit přímo v mysql rozhraní a žádné ztráty jsem nezaznamenal.
Subor ostane zaplneny.
Lenze viete ako. Pri vypadku prudu sa ziadne sync nepodari nahodit. Takze v tomto smere mi ide o princip. Ako XFS funguje.
Btw: Vcera som skusal XFS vs. EXT3 na 1.2 TB particii.
Mam z toho zmiesane pocity.
Skusal som ho zatazit napriklad tym, ze som mu dal vygenerovat 100 suborov o velkosti 30MB. Particia s XFS bola oproti EXT3 o 3 sekundy lepsia. ALE POZOR: Len pri vytvarani suborov. Pri ich prepisovani si naskok udrzala EXT3.
Dalsia vec. Pri vytvarani tychto fajlov dosahovala rychlost XFS az 330MB/s. Naproti tomu kazdych cca 10 suborov sa o nieco spomalil (cca: 50-110MB/s - asi nejaka maskarada s cache) a po 3-4 suborov sa zasa nachvilku rozbehol na plnych 330MB/s.
Naproti tomu EXT3 sa v priemere drzal na 210MB/s, co je teda o dost pomalsie ako XFS ale zasa si tuto rychlost udrzal stabilne a vyssie zmienovane spomalenie nebolo tak caste ako v pripade XFS. Tak ci onak - XFS vyslo o 3sec lepsie, cize nieco natom bude, ze je rychlejsie... .
asi nejaka maskarada s cacheZkuste si pohrát s dirty_writeback_centisecs a ostatními šoupátky.
Takto. Viete co mam k dispozicii. Viete naco to potrebujem.
Co mi odporucate?
Cele som to skratil a rozhodujem sa uz fakt len medzi XFS a EXT3.
Fakt, ze jste byl ochoten venovat svuj cas na testy s havarii/vypadkem proudu znamena, ze pro vas je to realna moznost. Takze ext3.Jenže použití ext3 problém s výpadkem napájení nebo pádem systému neřeší, pouze před ním zavírá oči. Pokud nastavíte synchronizaci na disk na stejný interval, bude rozdíl jediný: XFS poškozený soubor přizná, ext3 ho nepřizná a "doufá", že se na to nepřijde. Pokud byste chtěl souborový systém zabezpečený proti výpadku napájení, musela by se žurnálovat i data. Pokud by přišel požadavek na zápis, nejprve by se nová data zapsala do logu a udělal by se sync. Pak by se data zapsala na správné místo a záznam v logu by se potvrdil (poznamenalo by se, že byl aplikován). Teprve pak by se aplikaci vrátilo, že se data zapsala. Pak by bylo možné zajistit, že pokud kdykoliv dojde k výpadku, bude možné data na disku dostat buď do stavu po zápise, nebo před ním, ale nezůstanou v nějakém mezistavu. Pokud váš FS žurnál pro data nepoužívá, může vždy dojít k výpadku proudu v okamžiku, kdy z jednoho bajtu bylo zapsáno třeba 5 bitů a 3 ne -- a dostanete nekonzistentní data.
Aby som trosku uviedol veci na pravu mieru a zhrnul to.
---------------------------------------------------------------------------------------------------
Na server bude mat pristup par ludi, co budu uploadovat (max: 200-300 MB fajle) cez web rozhranie (cez nejaky PHP skript) a potom k tomu bude mat pristup dalsia skupina ludi, ktori budu tieto fajle cez web stahovat. Server je umiestneny v profesionalnom SERVERHousingu, kde by nemalo dojist k vypadku prudu. Aspon to tak deklaruju, ze maju k dispozicii generatory+UPSka, keby k niecomu doslo.
Cize v tomto smere tiez neocakavam problemy.
Preco uvazujem na zmenou FS?
Uz jednu generaciu servera s 2TB diskom som mal. A mal som ho naformatovany len na ext3. Stav po dvoch rokoch je taky, ze ext3 sa pomerne tazko pohybuje na particii velkej >1TB v ktorej je cca 8000 suborov v jednom adresari. Mam skripty, ktore kazdu noc prehliadaju disky, robia zoznam fajlov, porovnavaju s MySQL DB a podla toho ich bud zmazu alebo nechaju "zit".
S pribudajucim casom (a poctom suborov) mi tato nocna aktivita zoziera velke percento CPU, diskovej aktivity aj na niekolko HODIN. A vsetku vinu pripisujem prave EXT3jke.
Teraz mam server doma, mam ho moznost preinstalovat a znova pripravit na chod na dalsie 2 roky. Tuto moznost uz nebudem mat tak skoro, preto chcem vsetkej konfiguracii venovat patricnu pozornost. Tyka sa to aj vhodnemu vyberu FS. Za posledne 4 dni som prestudoval snad vsetko na internete co sa filesystemov tyka. A dospel som k nazoru, ze:
JFS - rychly, nenarocny ale s pribudajucim casom = velka fragmentacia = rapidne znizujuci sa vykon + nepritomnost defrag. nastroja pre linux = NO CHANCE.
ReiserFS - nepacia sa mi niektore topici o nom (a nasiel som ich dost), ze to ludom v urcitych situaciach nenavratne zhavarovalo + ten vyvoj je taky.... vseliaky, neisty. + nepouzivam vela malych suborov ale vela obrovsky suborov = NO CHANCE.
ext3 - nie prilis lichotiva skusenost s predoslej verzii mojho servera.
XFS - laka ma to. Ale nechcem skocit nevedomky do nejakej sracky! Fakt, ze subor pri zapise a pri vypadku ostava znulovany -- by mi nevadil. Dokonca to beriem mozno este aj ako vyhodu. Ja totiz nebudem vediet cez web-upload (vid info vyssie) nadviazat na ukonceny upload a pokracovat v nom. Jedina cesta pre mna bude zacat uploadovat novy subor. V tomto smere sa mi zda filozofia nuloveho fajlu odost lepsia. Navyse XFS potrebujem dat len na particie s daatami. Nie so systemom. System hodim do EXT3.
Cize realne z toho co ste mi sem vsetcia napisali + co som sa mohol docitat mi vychadza, ze XFS by malo byt vhodne. A ak nie, tak dalsie v poradi EXT3.
Ostava len posledna otazka, ktora asi rozhodne o vsetkom a to: " Na ktorom FS sa bude bash-skriptu, spustaneho cez crona lepsie pohybovat medzi 8000 subormi? Na Ext3jke alebo na XFScku?"
Ext3 ma uz v tomto smere trochu sklamala (z predoslych skusenosti). Mozno by som ju mal skusit vytuningovat. (http://www.iprint.sk/ext3-tunning).
Problem je, ze nemam cas :-(( Dnes sa musim rozhodnut a zit s tym dalsie dva roky.
Aaaaaaaaaaaa ako v tomto smere zavidim Windowsom. Tam je len jedna moznost = nie je co riesit. )
cca 8000 suborov v jednom adresariMožná by veškeré Vaše trápení vyřešilo rozdělení dat na několik adresářů. (Např. podle prvního jednoho nebo dvou písmen, jak to má squid.) A nebo kdoví jak to řeší ten Váš skript, třeba by stačilo ho trochu algoritmicky upravit.
snip
Server je umiestneny v profesionalnom SERVERHousingu, kde by nemalo dojist k vypadku prudu. Aspon to tak deklaruju, ze maju k dispozicii generatory+UPSka, keby k niecomu doslo.
/snip
:) Zrovna včera v noci byl v jednom nejmenovaném velkém pražském serverhousingu výpadek natvrdo - generátory neutáhly všechny stroje, tak některé haly natvrdo odpojili.
Zdravím Vás , nebál bych se XFS . XFS je rychlé , nemám problém s >2TB , pro našeho zákazníka jsem dodával server s 24*750GB disky SATA a server-NAS pole jede dodnes bez výpadku ( 2x opteron , XFS , RED-HAT ) .
Vše běželo na XFS v RAID5 , na tomto systému běží u nás celá nemocnice .... , těchto zařízení jsme dodávali celkem hodně. JFS+REISER no asi ne , já se kloním k XFS.
Mno a nestacilo by delat RSYNC kazdou noc na druhy disk treba u Vas doma? Pak uz by Vam vypadek vubec vadit nemusel a RSYNC je celkem rychly, kdyz se spravne nastavi.
K tomu reiserfs. Oni jsou 2 verze reiserfs3 a reiserfs4. Nejisty vyvoj je jen u reiserfs4. Reiserfs3 je vyvinuta a spolehliva a je soucasti kernelu.
O ext3 jsem cetl dost nelichotive veci. Nekdy se stava, ze po tvrdem vypadku vyzaduje check a ten muze trvat i par hodin. Me se jeste nestalo, ze by check system nespravil, ale oprava 20GB trva na mem pocitaci hodinu.
Rsync na 3x1.2 TeraBajtove disky?
Opravte ma ak sa mylim ale nie je rsync nieco ako file transport protocol??
Rsync je celkem brutalne rychly , kdyz se pouziva na NFS to NFS pak dokaze vytizit linku na 100% , rsync se pouziva treba na kopii 1:1 vzdaleneho a mistniho systemu. Rsync je hodne pouzivany na zalohy z produkcniho na backup server. Pouziva se i na prenosy vetsich souboru , ale hlavne pro synchronizaci , pouziva se i pro FTP prenosy.
rsync
se snaží přenášet jenom změny, takže pokud se za den změní třeba 100 MB, přenese jen těch 100 MB + nějaká řídící data. Jenom je potřeba dát pozor na přepis souborů a mazání, pokud byste měl jen jednu zálohu -- když někdo omylem smaže soubor, v noci se smaže i ze zálohy a druhý den byste to zjistil, bude vám už záloha k ničemu. Low-endové terabajtové SATA disky jsou dneska za pár peněz, neměl by být takový problém připojit je třeba k domácí počítači a v noci zálohovat tam. Pokud tedy nemáte připojení k internetu s nějakým FUPem...
Mam to chapat tak, ze ked databazovy subor ktory ma 1GB a pribudlo tam za den 10MB dat, tak rsync prekopiruje len tu 10MB zmenu (co sa mi zda scifi) alebo sa bude snazit prekopirovat cely 1GB subor lebo zistil ze je v nom zmena ?
Tiskni
Sdílej: