Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Současné vývojové jádro 2.6 je stále 2.6.29-rc7; během minulého týdne nevyšly žádné předverze. Od vydání 2.6.29-rc7 bylo do hlavní řady začleněno okolo 160 oprav; předverze -rc8 se dá očekávat ve velmi blízké budoucnosti.
Současné stabilní jádro 2.6 je stále 2.6.28.7; od 20. února nebyly vydány žádné aktualizace.
-- Ted Ts'o
Souborový systém ext4 nabízí mnoho užitečných vlastností. Stabilizoval se rychle, ale to neznamená, že bude každému fungovat perfektně. Vezměme třeba tento příklad: bug tracker v Ubuntu obsahuje záznam "ztráta dat na ext4", kde nešťastný uživatel ext4 hlásí:
Autor tohoto článku neměl v úmyslu o tomto problému psát (zatím), ale poměrně hodně čtenářů navrhovalo, abychom se na to podívali. Vzhledem k tomu, že zájem zde zjevně je, tady je rychlý pohled na to, co se děje.
První unixové (a linuxové) systémy byly známy tím, že se při pádu systému ztrácí data. Bufferování zápisů do souborového systému, přestože je dobré pro výkon, způsobuje, že data uložená v bufferu se při neočekávaném vypnutí ztrácí. Uživatelé Unixu o této možnosti věděli; měli z ní obavy, ale ztráta výkonu spojená se synchronním zápisem obecně podle mínění většiny nestála za to. Tvůrci aplikací se tudíž museli hodně snažit, aby zajistili, že data, která opravdu musí být na fyzickém médiu, se tam dostanou rychle.
Novějším uživatelům Linuxu může být odpuštěno, pokud si myslí, že tento problém byl zcela vyřešen; se souborovým systémem ext3 je ztráta dat při pádu systému mnohem méně pravděpodobná. To je téměř náhodný důsledek některých rozhodnutí při návrhu ext3. Děje se toto:
Ve výchozím nastavení ext3 ukládá každých pět vteřin změny do svého žurnálu. To znamená, že všechny změny metadat jsou uloženy a přetrvají, i když systém následně spadne.
Ext3 (ve výchozím nastavení) neukládá zapisovaná data do žurnálu. Ve (výchozím) režimu data=ordered jsou však všechny modifikované bloky vynuceně uloženy na disk předtím, než se změny metadat uloží do žurnálu. Vynucené uložení se provádí, aby se zajistilo, že když systém spadne, uživatel nebude schopen číst předchozí obsah postižených bloků - to je bezpečnostní opatření.
Konečným výsledkem je, že data=ordered v podstatě zajišťuje, že data zapsaná do souboru budou o pět vteřin později skutečně na disku. Obecně se tedy při pádu může ztratit pět vteřin zapisování.
Jinými slovy, ext3 poskytuje relativně vysokou úroveň odolnosti proti pádům, i když tvůrci souborového systému nikdy toto chování nezaručovali a POSIX ho rozhodně nevyžaduje. Jak to Ted shrnul ve svém mučivě jasném a pochopitelném vysvětlení situace:
Ať už je náhodná, nebo ne, zabránění ztrátě dat vypadá jako hezká vlastnost, kterou by souborový systém mohl mít. Proto by se dala položit otázka, co by mohlo vývojáře ext4 vést k tomu ji odstranit. Odpovědí je samozřejmě výkonnost - konkrétně zpožděná alokace.
"Zpožděná alokace" znamená, že se souborový systém pokouší pro zapisovaná data zpozdit alokaci fyzických bloků na disku tak dlouho, jak je to možné. Tato politika přináší důležité výkonnostní zisky. Mnoho souborů má krátký život; zpožděná alokace může zajistit, že se tyto poletující soubory vůbec nebudou zapisovat. A u déle existujících souborů zpožděná alokace jádru umožňuje nashromáždit víc dat a alokovat bloky pro tato data spojitě, čímž se zrychlí jak zápis, tak i následné čtení dat. Je to důležitá optimalizace, kterou lze nalézt ve většině současných souborových systémů.
Jestliže ale pro soubor nebyly alokovány bloky, není je potřeba v rámci bezpečnostního opatření rychle zapisovat na disk. Vzhledem k tomu, že bloky ještě neexistují, není možné číst z nich data někoho jiného. Ext4 tedy nezapisuje (nemůže) nealokované bloky jako součást cyklu zapisování žurnálu. Tato data místo toho čekají, dokud se jádro nerozhodne je zapsat; v tu chvíli jsou na disku alokovány fyzické bloky a data jsou zvěčněna. Jádro nerado nechává data nezapsaná příliš dlouho, ale ve výchozím nastavení může trvat přibližně minutu, než se zapíší - což je mnohem déle, než je obvykle k vidění u ext3. A to je důvod, proč pád způsobí ztrátu o něco více dat, když se používá ext4.
Správné řešení je opravit aplikace, které od souborového systému očekávají více garancí, než skutečně poskytuje. Aplikace, které často přepisují mnoho malých souborů, se zdají tímto problémem obzvláště zranitelné; měly by použít lepší formát na disku. Aplikace, které si chtějí být jisté, že jejich soubory byly zapsány na médium, mohou použít systémová volání fsync() nebo fdatasync(); to je důvod, proč tato systémová volání existují. Donutit aplikace chovat se podle toho, co systém skutečně poskytuje, je lepší řešení, než snažit se věci opravit na jiných úrovních.
Bylo by nicméně hezké zlepšit robustnost systému, zatímco budeme čekat, než si vývojáři aplikací všimnou, že mají práci. Jedno možné řešení je samozřejmě prostě používat ext3. Další je zkrátit dobu pro zpětný zápis, která je uložena v několika sysctl proměnných:
/proc/sys/vm/dirty_expire_centisecs /proc/sys/vm/dirty_writeback_centisecs
První z těchto proměnných (dirty_expire_centisecs) řídí, jak dlouho data mohou sedět v cache stránek předtím, než jsou považována za "prošlá" a naplánována k zápisu na disk; výchozí je 30 sekund. Hodnota dirty_writeback_centisecs (výchozí 5 sekund) řídí, jak často se probouzí proces pdflush, který má prošlá data zapsat na disk. Snížení těchto hodnot způsobí, že systém bude data na disk ukládat agresivněji za cenu snížené výkonnosti.
Třetí, částečné řešení existuje v sadě patchů plánovaných do 2.6.30; ty přidávají sadu heuristik, které se pokoušejí chránit uživatele před nejhorším škodami v určitých situacích. Jsou to:
Patch, který přidává nový ioctl() příkaz EXT4_IOC_ALLOC_DA_BLKS. Když je zavolán pro soubor, donutí ext4 alokovat všechny bloky se zpožděnou alokací. Tím se dosáhne efektu zapsání dat souboru na disk relativně rychle a zároveň se vyhne plné režii (těžkotonážního) volání fsync().
Druhý patch nastavuje speciální příznak u souboru, který byl zkrácen; když je soubor uzavřen, vynutí se všechny zpožděné alokace. To by mělo zabránit problému "souborů nulové délky" hlášeném na začátku.
A nakonec tento patch, který vynucuje alokaci bloků, když je jeden soubor přejmenován na jiný. To je taktéž zaměřeno na problém často přepisovaných malých souborů.
Společně by tyto patche měly zmírnit nejhorší problémy ztráty dat a přitom zachovat výkonnostní zisky, které pocházejí ze zpožděné alokace. Nebyly však navrženy k začlenění takto pozdě ve vývojovém cyklu 2.6.29; jsou dost velké na to, aby musely čekat na 2.6.30. Distributoři dodávající starší jádro mohou samozřejmě tyto patche backportovat a někteří to možná udělají. Měli by si ale také z celé této epizody odnést poučení: ext4, přestože je na první pohled stabilní, je stále velmi mladý souborový systém. Na experimentující uživatele může čekat ještě pár překvapení.
Mnoho vývojářů jádra nemusí během celé své kariéry na strukturu buffer_head vůbec narazit. Čelo bufferu [buffer head] (často nazývané bh) nicméně sedí v centru jaderné správy paměti a vrstvy souborového systému. Jednoduše řečeno, bh udržuje mapování mezi specifickou stránkou (nebo její částí) v RAM a odpovídajícím blokem na disku. V dobách 2.4 byla struktura bh také klíčovou částí blokové I/O vrstvy, ale 2.6 toto konkrétní spojení odstranilo. Nehledě na to, toto přízemní, často kritizované bh stále hraje klíčovou roli v současných jádrech.
Proč "často kritizované"? Čela bufferů je obtížné spravovat, a to až v takovém rozsahu, že mohou na některých systémech způsobit značnou spotřebu paměti. Pracují s velmi malými jednotkami I/O (512 bytů), takže jich je potřeba několik, aby reprezentovaly jedinou stránku. A když s nimi pracujete, máte určitý pocit starobylosti; kód čela bufferu je jedna z nejstarších částí vnitřního jádra [core kernel]. Je to ale důležitý a ošidný kód, takže jenom pár vývojářů si troufne ho vylepšovat.
Nick Piggin je troufalý. Ale také se nesnaží vylepšit bh vrstvu; místo toho by ji rád úplně vyměnil. Výsledkem je strašidelná sada velkých patchů známá jako "fsblock". Kód byl poprvé zaslán v roce 2007, takže podle standardů patchů správy paměti je poměrně mladý. Sada patchů byla zaslána znovu začátkem března; během té doby se dočkala mnoha vylepšení. Nick říká: Mám v úmyslu ji dříve či později dovést k začlenění, takže tohoto kódu v budoucnu pravděpodobně uvidíme více.
Centrální datovou strukturou je struct fsblock, která reprezentuje jeden blok:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct fsblock {
unsigned int flags;
unsigned int count;
#ifdef BDFLUSH_FLUSHING
struct rb_node block_node;
#endif
sector_t block_nr;
void *private;
struct page *page;
};
Tato struktura, poznamenává Nick, má oproti struct buffer_head třetinovou velikost, ale slouží přibližně stejnému účelu: sledování spojení mezi blokem v paměti (k nalezení v page) a jeho verzí na disku indexovanou block_nr. Pole flags popisuje stav tohoto bloku: jestli je aktuální (verze v paměti a na disku souhlasí), zamčený, nečistý [dirty], zpětně zapisován [in writeback] atd. Některé z těchto příznaků (například stav špinavý) souhlasí se stavem uloženým ve stránce v paměti; vrstva fsblock (na rozdíl od kódu buffer_head) velmi pečlivě zachovává tyto příznaky synchronní.
Ve struktuře fsblock je pár zajímavých příznaků, které v buffer head nenajdete. Jeden z nich vlastně vůbec není příznak: BL_bits_mask popisuje podpole udávající velikost bloku. Ve fsblock nejsou "bloky" omezeny na standardní velikost sektoru 512 B; mohou být ve skutečnosti dokonce větší než stránka. Tyto "nadstránkové" bloky jsou na seznamu přání některých vývojářů souborových systémů již po nějaký čas; zjednodušily by vytvoření souborových systémů s velkými bloky, které by se v mnoha situacích chovaly lépe. Nadstránky nicméně mohou být v prvních začleněních kódu fsblock odstraněny, aby byl kód snáze pochopitelný a revidovatelný. Krom toho jsou velké bloky poněkud kontroverzní téma, takže dává smysl se jimi zabývat zvlášť.
Pole flags také obsahuje příznak nazvaný BL_metadata; tento příznak označuje blok, který obsahuje metadata souborového systému, a ne data souborů. V takovém případě je blok ve skutečnosti částí větší struktury, která (po malé editaci) vypadá nějak takto:
struct fsblock_meta {
struct fsblock block;
union {
#ifdef VMAP_CACHE
/* souborové systémy používající API vmap by neměly používat ->data */
struct vmap_cache_entry *vce;
#endif
/*
* data je přímé mapování na data blokového zařízení používané
* souborovými systémy ve "zprostředkujícím" režimu.
*/
char *data;
};
};
Tato struktura kódu souborového systému zjednodušuje přímou práci s bloky metadat. Struktura fsblock_sb nakonec připojuje superblok souborového systému do subsystému fsblock.
Souborový systém může při připojování věci nastavit voláním:
int fsblock_register_super(struct super_block *sb,
struct fsblock_sb *fsb_sb);
Superblok lze poté číst voláním sb_mbread():
struct fsblock_meta *sb_mbread(struct fsblock_sb *fsb_sb,
sector_t blocknr);
Je zde jenom jeden malý problém: předtím, než může fsblock provádět blokové I/O operace, musí mít přístup k superbloku. Zatím tedy souborové systémy, které byly konvertovány k používání fsblock, musí stále používat pro čtení superbloku API buffer head. Lze předpokládat, že o tento háček bude v nějakém bodě postaráno.
Kompletní prohlídka API fsblock by vyžadovala několik článků - je to spousta kódu. Snad rychlý přehled naznačí, jak to celé funguje. Začněme tím, že bloky jsou ve fsblock objekty s počítanými odkazy, takže je zde obvyklá sada funkcí pro inkrementaci a dekrementaci čítačů:
void block_get(struct fsblock *block); void block_put(struct fsblock *block); void mblock_get(struct fsblock_meta *block); void mblock_put(struct fsblock_meta *block);
Je zde celá sada funkcí pro provádění I/O na blocích a blocích metadat; některé z nich jsou:
struct fsblock_meta *mbread(struct fsblock_sb *fsb_sb, sector_t blocknr,
unsigned int size);
int mblock_read_sync(struct fsblock_meta *mb);
int sync_block(struct fsblock *block);
Všimněte si, že i když je mnoho funkcí pro čtení bloků, pro zápis jich je méně. Místo toho kód použije funkci jako set_block_dirty() nebo mark_mblock_dirty() a nechá na kódu správy paměti, kdy se I/O skutečně provede.
Fsblock toho obsahuje mnohem víc, včetně funkcí pro zamykání bloků, vyhledávání bloků v paměti, provedení I/O stránky, zkracování stránek, implementaci mmap() a dalších. Lze předpokládat, že Nick určitě brzy napíše rozsáhlou dokumentaci tohoto API.
Kromě tohoto malého dokumentačního úkolu zbývá jenom pár dalších věcí, včetně podpory přímého I/O a opravení mnoha známých chyb. Už nyní má ale fsblock, zdá se, velký potenciál; aktualizuje staré API buffer_head způsobem, který je efektivnější a robustnější. Také se zdá, že se souborovým systémem ext2 je výkonnější - což je fakt, který je pro Nicka překvapující. Fsblock tedy bude téměř určitě dříve či později začleněn. Mezitím se toho nicméně může stát mnoho. Podobné patche spojené s vnitřním kódem správy paměti jsou notoricky známy tím, že se přes proces začleňování propracovávají pomalu, a přes své stáří kód fsblock doteď nezažil mnoho revizí. Ostatním vývojářům tedy pravděpodobně zbývá spousta času a příležitostí najít věci, se kterými nebudou souhlasit, předtím, než se fsblock dostane do hlavní řady.
Originál tohoto článku napsal Goldwyn Rodrigues
Jak se kapacita úložných zařízení zvyšuje a zvyšuje, plošná hustota (počet bitů uložených na centimetru čtverečním) roste; pevné disky se nyní blíží k limitům. Výrobci pevných disků nyní tlačí na to, aby se zvětšila základní přenosová jednotka pevných disků - velikost fyzického sektoru - z 512 bytů na 4096 bytů (4 kB) a tím zlepšila efektivita a výkonnost ukládání. Touto změnou je nicméně ovlivněno mnoho subsystémů, které v současnosti nejsou připraveny velikost sektoru 4k přijmout.
První pevný disk, RAMAC, byl prodáván 13. září 1956. Vážil 2 140 liber (970 kg) a měl celkovou kapacitu 5 MB dat na padesáti 24palcových plotnách. Byl pronajímán za 35 000 dolarů, což odpovídá dnešním 300 000 dolarům.
Od té doby jsme ušli dlouhou cestu. Kapacity pevných disků se nyní udávají v terabytech, ale některé staré parametry, jako velikost sektoru, se nezměnily. Velikost sektoru je do mnoha datových struktur v jádře zadrátována napevno, pole i_block ve struct inode například udává počet 512 bytů velkých fyzických bloků, které zabírá na médiu. I když vnitřek jádra [core kernel] používá 512bytové sektory, bloková vrstva je schopna obsluhovat hardware s jinými velikostmi sektoru.
Všechny druhy datové komunikace se musí potýkat se šumem. Šum je také přítomen během přenosu dat z magnetického povrchu fyzické plotny na hlavičku disku; šum může být zanesen fyzickými defekty plotny disku. Při měření se takový šum porovnává se silou signálu, výsledná hodnota je známa jako poměr signál/šum [signal-to-noise ratio, SNR]. Jak se plošná hustota disku zvětšuje, poměr signál/šum klesá, takže citlivost na defekty roste.
Pevné disky k datům přidávají speciální rezervované bity nazývané kód pro korekci chyb [Error-Correction Code, ECC]. Každý blok fyzických dat je na fyzickém médiu kromě jiného následován ECC byty. ECC zodpovídají za spolehlivost přenášených dat, obvykle se tyto bity počítají použitím Reed-Solomonova algoritmu, který umožňuje detekovat a v určitém rozsahu i opravit chyby při čtení; je to efektivní algoritmus pro opravování blokových chyb. ECC bity jsou umísťovány hned za datové byty (jak je vidět z obrázku níže), takže chybu, pokud se objeví, je možné opravit hned s tím, jak se disk otáčí. Kromě ECC má disk také bity rezervované před datovými bity pro preambuli a synchronizační značku; za ECC bity je mezisektorová mezera [Inter Sector Gap, ISG].
Se zvýšením plošné hustoty je na čtvereční centimetr fyzického povrchu uskladněno více bitů. Fyzický defekt o velikosti řekněme 100 nanometrů tedy potřebuje pro korekci více ECC bitů, než je potřeba u menších hustot. Fyzické defekty zavádějí více šumu, takže SNR se snižuje. To vyžaduje přibalit k sektoru více ECC bytů, aby se kompenzoval pokles SNR a zajistila spolehlivost dat uložených na disku. Například: na disku s hustotou 215 kbpi (kilobitů na čtvereční palec) potřebuje 512bytový sektor 24 bytů ECC; efektivita formátu (množství uživatelských dat proti celkovému počtu dat na disku) je 92 %. Se zvýšením plošné hustoty na 750 kbpi potřebuje každý 512bytový sektor 40 bytů, aby se zajistila stejná spolehlivost; efektivita formátu je 87 %.
Sektor o velikosti 4096 bytů potřebuje 100 bytů ECC, aby se zajistila stejná úroveň spolehlivosti při 750 kbpi; z toho plyne efektivita formátu 96 %. Jak se plošná hustota diskových jednotek stále zvyšuje, fyzická velikost každého sektoru na povrchu disku klesá. Pokud střední velikost a počet defektů a škrábanců neškáluje ve stejném tempu, lze očekávat, že blokové chyby mnohem snáze překročí schopnost jednotlivého sektoru opravovat chyby. Větší sektory by umožnily odhalit takové blokové chyby, čímž by se snížila celková režie za ECC. Kromě ECC má disk před datovými bity také rezervované bity pro preambuli, synchronizační značku a mezisektorovou mezeru. Zvýšení velikosti sektoru z 512 bytů na 4k by snížilo četnost těchto polí, čímž by se efektivita formátu ještě zvýšila.
Ze všech těchto důvodů se chce průmysl úložných zařízení přesunout k větším velikostem sektoru. Byla založena Mezinárodní asociace pro výbavu a materiály diskových jednotek [International Disk Drive Equipment and Materials Association, IDEMA], jejímž cílem je zvýšit spolupráci mezi konkurujícími značkami pevných disků. IDEMA je zodpovědná za hladký přechod z velikosti sektoru 512 B na 4 kB. Také bylo založeno bigsector.org, které má udržovat dokumentaci o přechodu. Dokumentační sekce bigsector.org obsahuje o přechodu více informací.
Tato změna ovlivňuje hodně oblastí v řetězci úložného systému: od rozhraní disku, rozhraní hostitele, BIOSu, OS k aplikacím, jako jsou správci oddílů. Změna ovlivňuje tolik subsystémů, že nemusí být okamžitě přijata trhem. Pro plynulý přechod se plánují tyto kroky:
512B logická a 512B fyzická velikost sektoru. To je současný stav pevných disků.
512B logická a 4096B fyzická velikost sektoru. To umožní hladký přechod z 512B na 4096B velikost sektoru.
4096B logická a 4096B fyzická velikost sektoru. K tomu by došlo poté, co všechen hardware a software bude brát ohledy na změnu geometrie s ohledem na velikost sektoru. Tato změna bude nejprve k vidění u SCSI zařízení a poté u ATA zařízení.
Plánuje se, že během fáze přechodu (krok 2) budou disky používat emulaci 512B, známou jako číst-změnit-zapsat [read-modify-write, RMW]. Číst-změnit-zapsat je technika použitá k emulaci velikosti sektoru 512B na 4k fyzických sektorech. Zapsaná data, která neodpovídají celému 4k sektoru, jsou zapsána tak, že se nejprve načte existující 4k sektor, přepíše se část, která se změnila, a pak se celý 4k sektor zapíše zpět na disk. Více informací o RMW a implementaci lze nalézt na těchto slidech. Není potřeba říkat, že RMW snižuje propustnost zařízení, i když kratší ECC to vykompenzuje obecně lepší výkonností (snad). Očekává se, že tyto disky budou komerčně k dispozici v první čtvrtině roku 2011.
Matthew Wilcox nedávno poslal patch pro podporu 4k sektorů podle standardu ATA-8 (PDF). Patch přidává do rozhraní funkci sector_size_supported(). Jednotlivé ovladače musí tuto funkci implementovat a vrátit velikost sektoru používanou hardwarem. Vrácená velikost je uložena v poli sect_size struktury ata_device. Funkce vrací 512, pokud zařízení nerozpoznává příkaz ATA-8 nebo pokud ovladač neimplementuje rozhraní. sect_size se používá místo ATA_SECT_SIZE, když je datový přenos násobkem 512B sektorů.
Systém oddílů a zavaděče také bude potřeba změnit, protože nyní spoléhá na fakt, že oddíly začínají na 63. sektoru disku, což s 4k sektorem ukazuje na špatné místo. Krátkodobě bude tento problém řešen emulací 4k fyzický - 512B logický. 512B sektory jsou zarovnány tak, že první logický sektor začíná na prvním oktantu prvního fyzického 4k sektoru, jak je zobrazeno níže.
Toto schéma skládání logických a fyzických sektorů, aby se optimalizovalo ukládání dat a jejich přenos, je známo jako fyzické/logické sektory s lichým zarovnáním. Může ale vést k jiným problémům: sektory s lichým zarovnáním mohou špatně zarovnávat data s ohledem na bloky souborového systému. Když budeme uvažovat velikost stránky 4k, náhodné čtení bude vyžadovat čtení dvou sektorů. To je důvod, proč by aplikace, jako jsou zavaděče a systémy pro dělení disků, měly být připraveny na velikost sektoru pevných disků 4k (krok 3), kvůli celkové efektivitě a propustnosti.
Zvýšení velikosti sektoru je potřeba, aby pevné disky prolomily současná omezení kapacit a zároveň minimalizovaly režii kontroly chyb v datech. Hladký přechod nicméně rozhodne o tom, jestli budou tyto disky akceptovány trhem. Předchozí přechod, který prolomil limit 8,4 GB použitím přístupu k velkým bloků [Large Block Access, LBA], byl přijat snadno. S tolika disky, které se používají nyní, bude nicméně tento přechod ovlivněn spoluprací různých subsystémů řetězce předávání dat, jako jsou souborové systémy a aplikace obsluhující pevné disky.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
9.4.2009 18:39
Nicky726 | skóre: 56
| blog: Nicky726
LOL
Uvazujem o preklade "International Disk Drive Equipment and Materials Association, IDEMA". Viac by mi sedelo equipment = zariadenie. Takze potom "Medzinárodná asociácia pre diskové zariadenia a ich materiály". Nuz ale tazko to presne prelozit.
Clanocek standardne super. Vdaka.