Kdysi dávno, ještě na vysokoškolské koleji, mi kamarád ukazoval jak si kompiluje XFS filesystém, který tehdy nebyl ještě součástí jádra. V porovnání s tehdy jediným souborovým systémem ext2 byl XFS něco jako malý zázrak, žurnálování a z něj plynoucí především absence zdlouhavého fsck byla jasnou výhodou.
O něco později, když už byly žurnálovací systémy běžně v jádru, jsem na mém prvním hostingovém serveru přecházel z ext2 na reiserfs. Měl jsem s ním ale hrozné výkonostní problémy, reiser byl pomalý jak slimák, bylo to nepoužitelné. A světe div se, všechny výkonostní problémy zmizely po přechodu na XFS. Možná to nebylo filesystémem, ale diskem. Možná tím, že jsem při přechodu systémovou partišnu přeinstaloval a tudíž možná změnil ještě něco dalšího. A možná to bylo úplně něčím jiným, to už teď nezjistím. Každopádně XFS bylo svižné jak svižňa, takže jsem od té doby zavrhl všechny ostatní filesystémy a XFS používám naprosto všude. Výkon pro mé potřeby (webservery) absolutně vyhovující, jediné co bych uvítal vylepšit je rychlost mazání souborů, to je teda dost pomalé vytváří to vysoký load.
Nicméně i přes tento nedostatek jsem spokojen. Už několikrát jsem musel po havárii hardwaru xfs opravovat na degradovaných polích, a zatím vždy se mi povedlo vesměs všechny data dostat zpátky přes xfs_repair. Dnes jsem po letech ovšem natrefil na další (pro mě dosud neznámou) featuru, a tou je defrag. Celé roky jsem žil v mylném přesvědčení, že defragmentace není u XFS nutná, nicnémě opak je pravdou. Teda abych pravdu řekl, nevím jestli je NUTNÁ, nicméně je možná. A dokonce celkem jednoduše, a za běhu systému.
Tímhle příkazem se zanalyzuje diskový oddíl, pro každý soubor se spočítá počet fragmentů, a výsledek je vypsán:
root@darkstar:~# xfs_db -r /dev/sda5
xfs_db> frag
actual 198698, ideal 64254, fragmentation factor 67.66%
xfs_db> quit
Ve výpisu výše vidíme, že 67.66% dat je fragmentovaných ne moc ideálně, tudíž je na snadě spustit defragmentaci:
root@darkstar:~# xfs_fsr -v /dev/sda5
Program xfs_fsr sice jako parametr akceptuje soubor zařízení (diskového oddílu), nicméně pracuje s namountovaným filesystémem. Vyhledá soubory, které jsou příliš fragmentované, a opraví je tak, že ve stejném adresáři vytvoří jejich dočasnou kopii (pokud možno nefragmentovanou) a pak „přeznačkuje“ originální soubor, aby používal nová zkopírovaná data. Operace přeznačkování je atomická. Po provedené defragmentaci jsem se dostal na fragmentation faktor 2%, což vypadá mnohem líp :)
Jedno úskalí to ovšem má – někdy je pozici dat fyzicky na disku nutné udržet, např. LILO si fyzicky mapuje bloky na disku odkud čte vmlinuz při bootování. Proto je buď potřeba pomocí xfs_io označit patřičné soubory jako nedefragmentovatelné, nebo jednoduše po defragmentaci spustit lilo, aby si fyzické umístění kernelu refreshnulo.
Zajímavé, díky za info!
Jenom ze zvědavosti, má to nějaké praktické dopady, třeba na tu rychlost? Skutečně to XFS "potřebuje", jak tvrdí titulek postu?
A jak je to u ext2/3/4? Protože mám pocit, že mýtus, že Linux nepotřebuje defragmentaci právě pramení ve vlastnostech extů...
xfs_fsr bol/ je v Irixe (povodnom systeme kde XFS vznikla) standardne spustany cronom kazdy tyzden V nedelu nad ranom, takze by som povedal, ze prinos by to malo mat. Tento defrag bol obmedzeny casovo na 2 hodky, potom si ulozil subor planovanych zmien a pri nasledovnom spusteni ho nacital, porovnal zo zmenami a pokracoval dalej.
Inak som rad ze som objavil dalsieho cloveka co prepadol vyhodam XFS rovnako ako ja.
> LILO si fyzicky mapuje bloky na disku odkud čte vmlinuz při bootování..
/boot dávám zásadně na malou samostatnou partition na začátku disku. zatím se to vždycky vyplatilo :)
lilo neumělo - možná pořád neumí? - číst image z velkých disku za určitou hranicí.. root se dá zašifrovat nebo zrcadlit na nějakém raidu.. rootů může být víc, hlavně v době instalace nějaké novější verze.. může být readonly jako prevence některých útoků.. samá pozitiva a sociální jistoty ;-)
Myslím, že je důležité připomenout, že je zásadní nezaplňovat disk přes 3/4 jeho kapacity. To pak může být fs sebelepší a nic to nepomůže. Každý fs se časem fragmentuje. Otázka je taky, jaký to má pak účinek na rychlost - ne každá fragmentace brzdí! To, že 2 % vypadají lépe než 67,66 % ještě nic neznamená...
UNIX nepotřebuje defragmentaci, fragmentuje se automaticky sám.
Pouze se doporučuje zaplnit HDD do 80%. Na HDD ukládá data od "středu" disku, na rozdíl od OS Windows.
Jinak OS Windows a OS2-EcomStation, nejsou UNIX.
UNIX je BSD, Mac a Solaris jsou based a GNU/Linux je UNIX dle normy POSIX.
Takto mi to bylo kdysi vysvětleno.
[15]
jo,jo....
Na Wikipedii je zobrazení větvení UNIXu i GNU/Linuxu. Zadal jsem si v Googlu historii U a L. BSD je v podstatě OpenSource UNIX. První bylo asi OpenBSD a další FreeBSD. Z OpenBSD je NetBSD, to když se jeden vývojář dal svou cestou po sporu v kolektivu. No a PC-BSD je grafický fronted FreeBSD.
Co se týče Maca a Solarisu, tak ty jsou z BSD, nevím teď které verze. Snad 6 - 7. No a GNU/Linux, mám na mysli jen jádro Linux napsal Linus Torvalds inspirovaný Tanenbaumovým MINIXem. MINIX má ale jádro podobné jádru HURD, s mikrokernelem. Jádro Linux je monolit, nebo v případě OS Debian, Gentoo, monolit s moduly.
Jinak OS s jádrem Linux jsou Slackware, Debian a RedHat. Všechny ostatní z nich vychází i když se později stanou také nezávislé, např. Mandriva, Fedora,....
[14] Na to jste přišel jak? Fragmentuje se každý FS, který umožňuje znovu-používání místa po zrušených souborech, a zároveň soubory nemají fixní velikost (tj. nejspíš všechny FS které znáte). Samozřejmě se FS snaží fragmentaci předcházet. Pokud disk nezaplníte nad 90%, může se to FS celkem dobře podařit, v závislosti na druhu provozu na FS. Windows samozřejmě neukládají data od začátku disku, alokátor (část FS, která říká, na jaké místo na disku se souboru uloží) je podstatně komplikovanější :), a dělá svoji práci dost dobře.
Windows není UNIX, nicméně do Windows XP už po instalaci plní kritéria POSIX, tedy kritéria na získání ochranné známky UNIX. Protože POSIX subsystem ale skoro nikdo nepoužíval (s lehkým rýpnutím skoro stejně jako Linux), od Windows XP výše je ho (resp. SFU) třeba doinstalovat dodatečně. Výsledek je opět POSIX compliant. Mimochodem Linux je sice OS unixového typu, ale není POSIX compliant. Ad absurdum jsou Windows víc UNIX, než Linux.
[17] windows xp po instalaci POSIX? to je nejaky blud... http://en.wikipedia.org/wiki/POSIX
Pardon, před Windows XP. Nakonec už další věta uvádí, že od WinXP výše je se POSIX subsystem (resp. SFU) v případě zájmu doinstalovává.
http://support.microsoft.com/kb/308259
@Lael
http://cs.wikipedia.org/wiki/Linux_Standard_Base
A nevšimol som si, že by bežne každá edícia win mala v sebe tento balík ;)
Absurdný si ty keď tvrdíš, slušne povedané maximálne píčoviny.
@jaster_ba: Proč do toho taháte Linux Standard Base, když je řeč o POSIXu? Mezi LSB a POSIXem existuje řada konfliktů.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38825
[14] Vezmi HDD, zaplň ho MP3 a fotkama. Pak náhodně smaž polovinu MP3 a fotek. Poté na HDD nahraj BlueRay ripy co se vejde. Pak smaž všechny zbylé MP3 a fotky. Zbylé místo zaplň opět BlueRay ripy a můžeš nám dlouhé hodiny povídat o tom, jak tento HDD nemá fragmentaci, ale budeš jen a pouze pro smích.
[23] Ano mylis se:) NTFS neni vubec spatny filesystem jak ho popisujes. Ale to je jedno. Ono na filesystemu ta rychlost dneska uz moc nelezi.
Logicka cisla bloku na disku totiz neznamenaji nic. Prvni blok muze byt na zacatku plotny a ten druhy uplne na jine plotne o kus dal od aktualni polohy hlavy. V extremnim pripade i na druhem konci plotny a disk za pis az si nasklada dost dat. Zapis odeslany na disk nemusi znamenat zapis fyzicky. Dneska jsou disky inteligentni az hruza a taky hodne slozite. Neustale mne necim prekvapuji.
Aby jsi mohl optimalizovat zapis na disk tak musis mit dokumentaci od vyrobce toho daneho disku. Obvykle jsou takhle optimalizovane vetsi SANky.Ty maji i custom firmware do disku.
Takhle uz muzes sledovat jenom jestli zapis je sekvencni nebo nahodny pripadne jestli ty bloky jsou blizko sebe.
Problém čtení sektorů na přeskáčku by měl řešit přímo firmware disku. SCSI nebo SATA rozhraní totiž dovoluje posílat víc požadavů najednou a disk na ně odpoví v pořadí, jaké je pro něj výhodnější. Odpovědi přijdou asynchronně a napřeskáčku. Takže pokud potrebuju číst bloky 1, 10, 20, 5, 15, tak disk je pravděpodobně přečte v pořadí 1, 5, 10, 15, 20. Pokud je například blok 1 kvůli defektu přesunutý až na konec disku, pořadí odpovědí by bylo jiné. V rámci zjednodušení v tomto příkladu počítám s diskem velkým 20 sektorů :-).
Tohle samozřejmě neplatí pro IDE alias ATA alias PATA. Tam se poslal požadavek a pak už se dalo jenom čekat na odpověď. Teprve potom se mohlo žádat o další sektor. Ale tyhle disky jsou už naštěstí k vidění jenom v muzeálních počítačích.
Dokonce je už dnes problém koupit 3.5" PATA disk.
Tomáš je autorem několika více či méně známých projektů jak z oblasti operačních systémů, tak internetu. V současnosti samozvaný expert na Linux, Bash, PHP a MySQL.
Přečteno 25 945×
Přečteno 23 975×
Přečteno 19 499×
Přečteno 18 283×
Přečteno 12 887×