Jaderné noviny – 10. 3. 2010

Aktuální verze jádra: 2.6.34-rc1. Citáty týdne: Brian Swetland, Dave Airlie, Andrew Morton, Casey Schaufler, Ted Ts'o. Citáty 2: Zombie útočí. LogFS začleněn do hlavní řady. Patch – nový plánovač s časovým limitem. Začleňovací okno 2.6.34, část druhá. Nouveau a kompatibilita rozhraní. Disky se 4k sektory a Linux.

Obsah

Aktuální verze jádra: 2.6.34-rc1

Současné vývojové jádro je 2.6.34-rc1 vydané 8. března. Toto vydání přišlo dříve než obvykle, ale Linus si rezervoval právo přetáhnout ještě několik stromů. Takže jestli máte pocit, že jste mi poslali požadavek na přetažení, který byl přehlédnut, upozorněte mě na to; obecně je ale začleňovací okno zavřené. Jak jsem sliboval, jestli jste nechali svůj požadavek na přetažení na poslední den dvoutýdenního okna, budete muset čekat na okno 2.6.35. Uživatelé Nouveau by měli pamatovat na to, že toto jádro nemohou použít, pokud neaktualizují i svůj uživatelský prostor.

Od 2.6.32.9 vydaného 23. února nevyšly žádné aktualizace stabilních jader.

Citáty týdne: Brian Swetland, Dave Airlie, Andrew Morton, Casey Schaufler, Ted Ts'o

Velká motivace dávat deskám „rybí“ jména – pro lidi od marketingu jsou poměrně odpudivá, takže se nikdy nemohou splést se jménem konečného produktu a my se můžeme soustředit na práci na hardwaru.

selinuxové přeznačkování [relabels] je nový fsck

Chybějící changelog v patchi je obvykle dobrý příznak toho, že patch potřebuje changelog.

Takže nakonec nemá pravdu nikdo. S oběma můžete dělat užitečné věci, ale jak řekli všichni i jejich pomatení tarbíci, nikdo nemá Jediné Bezpečnostní Řešení. Ani SELinux, který ve skutečném nasazení porušuje některé základní bezpečnostní principy (vizte: „dost malé, aby to šlo analyzovat“). TOMOYO porušuje „nelze obejít“, kdyby si náhodou někdo chtěl myslet, že někomu nadržuju. Pche, ani Smack není perfektní, ale utopení tohoto koťátka nechám na jiných.

Pokud mluvíme jenom o podmínkách, které stanovuje GPL, jasně, nikdo licenci neporušil. Co se ale stalo, je to, že si někdo v podstatě řekl „Chci si zaexperimentovat na hromadě uživatelů, ale nechce se mi trávit čas tím, abych to udělal pořádně. Chci to vzít zkratkou; nechci řešit fakt, že bude nemožné testovat jádra bez přetahování frankensteinovských patchů mezi Fedorou 13 a Fedorou 12.“ To je jak lidi, kteří těží ropu v Arktickém oceánu, používají jednotrupové tankery a nechávají za sebou toxický odpad, ale potom řeknou „Hej, zákony říkají, že to, co děláme, je OK. Jděte pryč a neotravujte.“

Citáty 2: Zombie útočí

V <compress/mm.h> (na který by se měly naházet atomovky z oběžné dráhy – jen tak lze mít jistotu) to bylo dostatečně ošklivé; když teď ale vidím, že se to šíří, přecházím do plného režimu útok na zombie, chci nastartovat motorovku a běhat okolo nahý.

OK, tohle opravdu nechceme… už proto, že už teď není dost zombií. Naposledy jsem slyšel, že EPA zvažovala, že je prohlásí za ohrožený druh, ale zasekli se v byrokracii, protože neví, jestli je vůbec mohou považovat za „druh“ nebo jestli mají být klasifikovány do stejné skupiny s plísní, toxickým odpadem a prodejci Microsoftu.

Osobně si myslím, že bychom měli dát hlavy dohromady, shodnout se na frameworku a framework opravit tak, abychom vyřešili potřeby a vytvořili kladivo, šroubovák, vrtačku nebo co švýcarské armády a neměli 4 různé možnosti, z nichž žádná nesplňuje všechny požadavky a které nutí naše nepoučené uživatele vybrat si jednu z nich. Ale hej, všichni víme, že na to nedojde, takže se zase vrátím do svého šťastného vysněného světa, ve kterém Linus nepobíhá nahý s motorovkou.

LogFS začleněn do hlavní řady

Jaderné noviny se na LogFS, nový souborový systém cílený pro úložiště bez rotujících částí [solid state storage device], dívaly v roce 2007. Trvalo to dlouho, ale od 2.6.34 bude LogFS k dispozici v hlavní řadě; nechť benchmarkování započne.

Patch – nový plánovač s časovým limitem

POSIXový přístup k plánování v reálném čase je založen na prioritách: CPU dostane úloha o nejvyšší prioritě. Komunita výzkumníků se ale od priorit dávno odklonila a místo toho věnuje mnoho snahy plánování založenému na časovém limitu [deadline scheduling]. Plánovače s časovým limitem umožňují každému procesu stanovit vlastní „dobu vykonávání v nejhorším případě“ a časový limit, do kdy musí toto vykonání doběhnout; pak lze plánovat úlohy tak, aby všechny stihly svůj limit, přičemž se odmítají úlohy, které by mohly způsobit, že bude tento slib porušen. V oběhu je několik patchů s plánovačem podle časového limitu, ale patch SCHED_DEADLINE, jehož autorem jsou Dario Faggioli a přátelé, vypadá jako ten, který se v současnosti s největší pravděpodobností dostane do hlavní řady; Jaderné noviny se tímto patchem zabývaly v říjnu.

Nedávno byla zaslána druhá verze patche SCHED_DEADLINE. Změny odrážejí mnoho komentářů, které přišly po první verzi; mezi jinými je zde nová implementace mechanismu skupinového plánování [group scheduling]. V tomto patchi je však pravděpodobně nejvýznamnější první pokus řešit problémy s inverzí priorit, kde proces o nízké prioritě může držením sdíleného prostředku zabránit procesu o vyšší prioritě v běhu. Inverze priorit je složitý problém a v oblasti plánování s časovým limitem zůstává bez konečného řešení.

U klasického plánování v reálném čase je inverze priorit obvykle řešena zvýšením priority procesu, který drží prostředek vyžadovaný procesem o vyšší prioritě. U plánování podle časového limitu nicméně žádné priority nejsou, takže je zapotřebí jiná varianta tohoto přístupu. Nový patch používá „dědění časového limitu“ – pokud proces drží prostředek, který je vyžadován jiným procesem, jemuž zbývá méně času do limitu, držícímu procesu je posunut okamžik vypršení limitu, dokud prostředek neuvolní. V tu chvíli je také nutné neomezovat procesu propustnost (odejmutí CPU v případě, že je překročena oznámená doba běhu). To může následně vést k tomu, že bude CPU přetíženo – což je něco, čemu se plánovače s časovým limitem chtějí vyhnout – ale očekává se, že tento problém nebude významný.

Seznam „k vyřízení“ u tohoto patche má stále mnoho položek, včetně méně rušivého přiškrcování propustnosti, port pro strom realtime preempce, skutečně globální plánování s časovým limitem na víceprocesorových systémech (další obtížný problém) a další. Kód se však vyvíjí a očekává se, že Linux bude mít správný plánovač s časovým limitem někdy v nepříliš vzdálené budoucnosti – i když nelze přesně stanovit časový limit, protože doba vývoje v nejhorším možném případě stále není známa.

Začleňovací okno 2.6.34, část druhá

Do hlavní řady bylo od shrnutí z minulého týdne začleněno téměř 1600 neslučovacích sad změn; pro vydání 2.6.34-rc1 to celkem dělá něco přes 6000 sad změn. Mezi nejvýznamnější pro uživatele viditelné sady změn začleněné od minulého týdne patří:

S „pouhými“ 6000 sadami změn vypadá 2.6.34 na relativně klidný vývojový cyklus; jak 2.6.32, tak 2.6.33 měly přes 8000 sad změn, když vyšlo -rc1. Může to být tím, že bylo odvedeno méně práce, ale také možná některé stromy zůstaly na mraze kvůli Linusovu rozhodnutí začleňovací okno zkrátit. Linus naznačil, že by ještě mohl zvážit několik požadavků na přetažení, takže do jádra stále může přibýt několik dalších vlastností. Zůstaňte na příjmu.

Nouveau a kompatibilita rozhraní

Nedávná diskuze na linux-kernel, která občas sklouzla do flamewaru, řešila otázku stability rozhraní do uživatelského prostoru. Hlavní příčinou byla změna rozhraní ovladačů Nouveau pro grafické karty NVIDIA, ale skutečné problémy jdou hlouběji. I když politika hlavní řady jádra je, že rozhraní pro uživatelský prostor žije „navždy“, politika ve stromě staging je uvolněnější. Někteří, mezi něž patří i Linus Torvalds, si ale myslí, že ovladače ve staging, které byly dodávány ve velkých distribucích, by měly dodržovat přísnější standardy.

V právě uzavřeném začleňovacím okně 2.6.34 Linus přetáhl na žádost Davea Airlieho ze stromu DRM, ale okamžitě narazil na svém systému Fedora 12 na problémy:

Hmm. A co mám k čertu dělat s

(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15

Problém je důsledkem toho, že ovladač Nouveau změnil své rozhraní, což vyžadovalo upgrade na libdrm – což je upgrade, který na Fedoře 12 neexistuje. Změny v Nouveau byly backportovány do jádra Fedory 13 2.6.33, která se dodává s novým libdrm, ale vložení tohoto jádra do Fedory 12 se neplánuje. Uživatelé, kteří používají jádra Fedory aktualizovaná pomocí yum, na problém nenarazí, což Dave vysvětluje:

V současnosti to pro své uživatele ve Fedoře řešíme, máme seznam závislosti mezi uživatelským prostorem a jádrem a aktualizujeme potřebné kousky, když se aktualizuje jádro; je to náročné, ale to jsme museli přijmout, když jsme se rozhodli dostat nouveau k lidem. Mezi F11, F12 a F13 v současnosti udržujeme 3 verze API nouveau.

To ale znemožňuje na Fedoře 12 s NVIDIA grafikami testování novějších jader, což omezuje počet lidí, kteří mohou testovat. Navíc neexistuje ani žádná „dopředná kompatibilita“ – jádro a DRM knihovna se musí aktualizovat (nebo vracet ke starší verzi) současně. Linus má obavy ze ztráty testerů, kteří používají Fedoru 12, a z problémů, na které mohou narazit uživatelé Fedory 13 (v současnosti Rawhide) při pokusu hledat chybu v jádře půlením [bisect] – přechody přes bariéru změny rozhraní nejsou možné, přinejmenším ne snadno. Ve své původní stížnosti byl Linus charakteristicky odměřený: Takové revoluce nejsou přijatelné.

Ovladače Nouveau byly začleněny teprve do 2.6.33 na Linusovu žádost – nebo požadavek – a byly vloženy do stromu staging. Konfigurační volba jasně deklaruje nestabilitu rozhraní pro uživatelský prostor: Prosím vezměte na vědomí, že tyto ovladače jsou vyvíjeny a mohou obsahovat rozhraní pro uživatelský prostor, která se pravděpodobně v blízké budoucnosti změní.. Několik programátorů jádra tedy Linusova stížnost zmátla. Jesse Barnes se ptal:

Eh, takže rozbití ABI v ovladačích ve staging není ok? Spousta jiných ovladačů ze staging je v distribucích dodávána s kompatibilními rozhraními pro uživatelský prostor, ale myslel jsem si, že důvodem pro staging bylo opravit ABI předtím, než se ty věci dostanou do hlavní řady a dostane se k nim záruka zpětné kompatibility, což znamená, že se rozbíjení dá očekávat.

Jasně, je to na prd, ale co jiného by měli vývojáři nouveau dělat? Nechtěli tlačit nouveau do hlavní řady, protože ještě nebyli spokojeni s ABI, ale na tvoji žádost to stejně začlenili jako staging ovladač, takže teď už se nesmí hnout? Sorry, ale tohle celé je tak trochu wtf…

Linus ale souhlasí s tím, že rozhraní je potřeba změnit, jenom je nespokojen s tím, jak se to dělá. Protože na Fedoře 12 není novější libdrm k dispozici, nemůže ho testovat:

Nehodlám vydat jádro, které nemůžu testovat. Takže jestli nedostanu libdrm, které v prostředí mojí F12 bude fungovat, budu muset vrátit zpět patch, který jste po mně chtěli začlenit.

Samozřejmě to není jenom Linus, kdo nemůže testovat, takže by byl rád, aby se stalo něco, co by uživatelům Fedory umožnilo testovat a dělit jádra půlením. Vývojáři Nouveau nechtějí udržovat několik rozhraní a vývojáři Fedory (a dalších distribucí) nechtějí být v situaci, kdy budou muset testovat několik verzí knihovny DRM. Jak to řekl vývojář Nouveau v Red Hatu Ben Skeggs, nemáme v úmyslu držet tady orezlá API, když to nejsou ta, která potřebujeme.

Linus by byl rád, aby spolu mohly koexistovat různé libdrm, nejlépe tak, aby si mezi nimi X server vybral za běhu. Jak říká, server má potřebné informace a pokud bude nainstalováno několik knihoven, od té správné ho dělí jedno dlopen():

Kdo byl ten rozhodně-ne-raketový-vědec, který rozhodl, že správný postup je „zjistit verzi DRM, kterou podporuje jádro, a ukončit se s chybou, když nesedí“?

Chápete, co říkám? To, co mě teď zajímá, je, že na určitých sestavách není možné měnit jádra. To efektivně znemožňuje bezproblémové testování. A to opravdu je technický problém.

Dave Airlie mu nakonec pomohl získat a nainstalovat obě knihovny a nastavit symbolický odkaz, který mezi nimi (ručně) vybírá. To bylo dostatečné k tomu, aby se jádro dalo testovat, takže Linus daný patch Nouveau neodstranil. Je zde ale významnější otázka: Kdy by mělo být dovoleno změnit rozhraní do uživatelskému prostoru a jak to udělat?

Vývojáři Nouveau jsou poněkud nespokojení kvůli tomu, že se Linus a další pokouší změnit jejich model vývoje, přinejmenším částečně proto, že nikdy nežádali, aby bylo Nouveau začleněno. Linus ale netlačí tolik na vývojáře Nouveau, jako na distributora, který Nouveau začal distribuovat, aby vznikající problémy řešil. Podle jeho názoru, jakmile začne významný distributor dodávat kombinaci knihovna/jádro, která fungovala, je jeho odpovědností zajistit, že bude fungovat dál obzvláště těm, kteří by chtěli provozovat novější jádra.

Problém pro testery existuje, protože distribuce, v tomto případě Fedora, dodávala ovladač před jeho začleněním do hlavní řady jádra, což porušuje princip „nejprve do upstreamu“. Linus jasně říká, že problém nevyvolalo začlenění kódu, ale jeho dodávání:

Předěl nikdy nebyl „Linus to začlenil“, ale „Fedora to začala dodávat“. Tam začaly problémy se standardním jádrem z upstreamu.

Alan Cox nesouhlasí a dokonce proti Linusovi používá jeho vlastní citát z roku 2004, protože vývojáři Nouveau vyvíjí tak jako doteď; není jejich chyba, že byl kód dodáván a že je teď v upstreamu:

Někdo, kdo se nikdy nezavázal ke stabilitě, udělal dobře. Vymazali všechna stará rozbitá rozhraní, pročistili číslování svých ioctl a pak uklidili. To chápu jako akci někoho, kdo jednoduše neuznává, že máš právo řídit jeho vývoj, a kdo chce pracovat tak, jako dříve.

Konsenzus, alespoň mezi lidmi, kteří nevyvíjí grafické ovladače, je nicméně takový, že rozhraní pro uživatelský prostor by se měla odstraňovat postupně. To dává distributorům spoustu času čistě zvládnout změnu rozhraní. Tak se v podstatě mění rozhraní v hlavní řadě; i když se od těch pro uživatelský prostor očekává, že budou udržována navěky, občas se změní – po dlouhé době, kdy jsou označena za zastaralá. Ingo Molnár dokonce tvrdil, že rozbití ABI často vede k tomu, že projekt nesklidí úspěch, který by mohl mít:

Nikdy jsem nenarazil na situaci, kde by ve zpětném pohledu rozbití ABI u široce nasazovaného projektu mohlo být považováno za ,dobré‘ pro jakoukoliv příčetnou definici ,dobrého‘.

IMO je to opravdu tak jednoduché. U OSS je jenom málo bezpodmínečných pravidel, ale tohle je jedno z nich

Ted Ts'o považuje čistý přechod z jednoho rozhraní na jiné za vlastnost svědomitého člena komunity. Jestliže vývojáři nechtějí pracovat tímto způsobem, neměli by svůj kód zahrnovat do distribucí:

Říkáte, že to nechcete dělat? Pak si ten kód nechte pro sebe a nepouštějte ho do oblíbených distribucí jako Fedora nebo Ubuntu. Chcete víc testerů? Skvěle! Cena, kterou za to musíte zaplatit, je zprovoznění nějakého verzování ABI, abyste nemuseli mít „dny, kdy to všem chcípne“.

Pokud by k této situaci došlo u jiného ovladače, řekněme u téměř nepoužívaného WiFi zařízení, pravděpodobně by okolo toho bylo méně nebo žádný řev. Ale protože X jsou pro testery tak důležitou a viditelnou součástí, jejich rozbití se těžko skrývá. Linus vždycky tlačil na to, aby byla nejnovější jádra hlavní řady testována, takže by nemělo být tak překvapivé, že ho to, co se zde stalo, vůbec nepotěšilo.

Z této situace vyrašilo také několik poznatků. I když vývojáři rádi věří, že mají pod kontrolou to, kdy ABI spadne do garance kompatibility, ve většině případů to není pravda. Jakmile je rozhraní začleněno a uživatelský prostor ho začne používat, bude tlak na to ho udržovat. V několika ohledech to vývoj ztěžuje, ale zisk, který z toho plyne uživatelům, je velký.

Disky se 4k sektory a Linux

Téměř přesně před rokem Jaderné noviny zkoumaly problém disků se 4k sektory a důvody pro jejich zavedení. Ve zkratce přechod na 4kB fyzické sektory umožňuje výrobcům disků zvýšit hustotu úložného prostoru, což je v soutěživém tržním prostředí vždycky vítáno. V nedávné době se objevilo mnoho zpráv, že Linux není na práci s těmito disky připraven; jaderný vývojář Tejun Heo dokonce zaslal rozsáhlé shrnutí, které stojí za to přečíst. V něm tvrdí, že podpora logických sektorů o velikosti 4 KiB nefunguje ani v jádře, ani v programech na dělení disku. Jak ale ukázala následující diskuze, ve skutečnosti nejsme připraveni tak špatně.

Linux je plně připraven na změnu velikosti fyzických sektorů na úložném zařízení, a to již dlouho. Bloková vrstva byla napsána tak, aby se do ní nezadrátovávaly velikosti sektorů natvrdo. Počty sektorů a jejich pozice jsou na této úrovni jádrem opravdu spravovány v 512B velkých jednotkách, ale bloková vrstva je velmi opatrná v tom, aby veškeré I/O probíhalo v jednotkách o správné velikosti. Jeden by tedy doufal, že všechno bude Prostě Fungovat.

Jak ale poznamenává Tejunův dokument, jsou zde bohužel komplikace. Tyto komplikace pochází z toho, že zbytek světa není připraven na práci s něčím jiným než se sektory o velikosti 512B, počínaje BIOSy, které jsou k nalezení téměř na všech systémech. BIOS, který by uměl nabootovat z disku s velikostí sektoru 4k, je ve skutečnosti velice vzácná věc – pokud takový vůbec existuje. Oprava BIOSu je zjevně obtížnější, než by si jeden myslel, a evidentně není velká motivace to udělat. Martin Peterson, který odvedl spoustu práce ohledně podpory takových disků v Linuxu, poznamenává:

Část váhání ohledně toho, jestli pracovat na bootu ze 4kB lbs disků, je motivována obecným trendem v průmyslu přesunout boot na SSD. Existují SSD se 4kB LBS, ale u lokálního bootu se průmysl drží ATA.

Problém není jenom na úrovni BIOSu: Zavaděče (bez ohledu na to, jestli jsou zaměřeny na Linux) nejsou na práci s většími sektory připraveny; totéž platí pro nástroje na dělení disku a to ani nezmiňujeme širokou škálu jiných operačních systémů. Je potřeba něco udělat, aby disky se 4k sektory mohly se vším tím softwarem pracovat.

To něco je samozřejmě vložení mapující vrstvy někam doprostřed. Většina disků se 4k sektory proto bude implementovat různé velikosti logických a fyzických sektorů, přičemž hostitelskému počítači se budou prezentovat ty, které zůstanou velké 512 B. Systém poté může předstírat, že pracuje se stejným hardwarem jako vždycky, a všechno bude fungovat tak, jak je potřeba.

Samozřejmě až na to, že jsou tu komplikace. Zápis sektoru o velikosti 512 B na disk se sektory o velikosti 4 kB nyní disk donutí provést cyklus čtení-úprava-zápis [read-modify-write], aby se neztratila data ze zbytku sektoru. Tím se samozřejmě všechno zpomalí a také se zvýší riziko ztráty dat, když se něco pokazí během této operace. Aby se tomuto problému předešlo, operační systém by měl provádět přenosy o velikosti násobku velikosti fyzického sektoru, kdykoliv je to možné. Aby to mohl dělat, musí znát velikost fyzického sektoru; a jak se tak stává, tato informace je k dispozici, jádro ji využívá interně a exportuje ji přes sysfs.

I tak to ale není tak jednoduché. Linuxové jádro může používat sektory o velikosti fyzických sektorů a všechny přenosy zarovnat podle 4kB hranic od začátku oddílu. To ale bude fungovat mizerně, pokud nebude správně zarovnán oddíl jako takový – v takovém případě každý pečlivě připravený blok o velikosti 4 kB bude zasahovat do dvou fyzických sektorů – což není optimální výsledek.

Není překvapení, že špatně zarovnané oddíly nejsou jenom běžné; je to norma. Vezměme příklad: Autor článku na Jaderném summitu šťastně získal disk bez rotujících částí [solid-state drive] od Intelu, který rychle připojil a rozdělil pro používání. Byl to skvělý tah: S gitovými repozitáři se na SSD pracuje mnohem lépe. Rychlý pohled na tabulku rozdělení [partition table] však ukazuje tohle:

Všimněte si, že fdisk, přestože běžel s vypnutým režimem kompatibility s DOSem, zobrazil rozměry disku v hlavách a cylindrech. Není potřeba říkat, že toto zařízení nemá ani jedno; i na rotujících discích jsou tato čísla naprosto fiktivní; jsou dědictvím z temných dob, kdy ani Linux neexistoval. Tohle dědictví nám ale stále znepříjemňuje život.

Bylo nebylo, někdo řekl, že 63 sektorů (512 B velkých) je mnohem víc, než bude kdokoliv schopen nacpat do jediné stopy [track] na disku. Vzhledem k tomu, že na rotujícím disku je I/O zarovnané podle stop rychlejší, dávalo smysl zarovnat oddíly tak, aby data začínala na začátku stopy. Tradičně tedy první oddíl na disku začíná na (logickém) sektoru 63, což je poslední sektor první stopy. Tento sektor obsahuje blok pro boot; jakýkoliv souborový systém začíná na začátku další stopy. Takové umístění samozřejmě špatně zarovná souborový systém při jakékoliv velikosti fyzického sektoru větší než 512 B; logický sektor 64 (první datový sektor na oddílu) bude umístěn na konec 4 k velkého fyzického sektoru. Jakékoliv další oddíly na zařízení budou téměř určitě zarovnány stejně špatně.

Dalo by se dohadovat, že nejlepší řešení je se prostě na tento postup vykašlat a zarovnat oddíly správně; nemělo by být tak těžké naučit nástroje pro dělení disků řídit se podle fyzických velikostí. To rozhodně lze udělat, nástroje se v tomto ohledu chytají pomalu, ale dostatečně motivovaný správce systému je obvykle i nyní dokáže přesvědčit, aby zarovnávaly oddíly rozumně. Chybné zarovnání by tedy nemělo být neřešitelný problém.

Bohužel jsou zde komplikace. Zdá se, že Windows XP nejenom že očekávají oddíly, které jsou chybně zarovnané, ale že bez nich dokonce nedokáží správně fungovat. Jednoduše nelze provozovat Windows XP na zařízení, na kterém jsou oddíly vytvořeny správně s ohledem na velikost fyzických sektorů 4 k. Aby se s tím vypořádali, zavedli výrobci disků ještě horší hack: Přesouvají všechny logické sektory o velikosti 512 B o jeden dopředu, takže logický sektor 64 přistane na začátku fyzického sektoru. Jakýkoliv nástroj pro dělení disku, který chce věci rozvrhnout správně, tedy musí vědět, kde je ve skutečnosti začátek zařízení – a ne všechna zařízení jsou úplně vstřícná, když jde o získání této informace.

Při troše štěstí tento problém s posunem o jedničku zmizí dřív, než se z něj stane významnější záležitost. Jak to řekl James Bottomley: …naštěstí je takových disků v divočině k vidění jenom málo a doufáme, že je budeme schopni zastřelit, než se rozmnoží. To ale neřeší problém s rozvržením oddílů, které mají používat XP. Novější verze Windows se tímto problémem nemusí zabývat, protože s XP spoluexistují jenom výjimečně (a Windows se nikdy moc nezabývají spoluexistencí s jinými operačními systémy obecně). Linux na druhou stranu může být snadno nainstalován na stejný disk jako XP; to vede k různým požadavkům na zarovnání různých oddílů. Aby tohle fungovalo, to nebude žádná legrace.

Co se kompatibility s XP týče, nemyslím si, že bychom se měli tolik namáhat s tím, abychom to vyřešili. XP byly svým pánem zapřeny a virtualizace si podle mě poradí s tím zbytkem.

Možná je to opravdu tak, že na úložných zařízeních nové generace nebude tolik instalací XP, ale i tak může jejich chybějící podpora na některých místech způsobovat frustraci.

S tím související záležitost, na kterou Tejun poukázal, je formát oddílu pro DOS, který se stále široce používá, ale který končí na 2 TB, což se dnes nezdá být tak mnoho. Používání logických sektorů v tabulce oddílů by tento limit mohlo rozšířit až na 16 TB, ale to opět vyžaduje spolupráci s BIOSem – a stále to není mnoho. Dlouhodobé řešení by podle všeho mohl být přechod na jiný formát tabulky oddílů, jako je GPT, ale to pravděpodobně nebude snadné.

Ve shrnutí: Linux na tom s podporou 4k disků není tak špatně, obzvláště když nemusí takový disk sdílet se staršími operačními systémy. Stále je zapotřebí nějaká práce na úrovni nástrojů, aby tato podpora fungovala optimálně bez nutnosti nízkoúrovňových zásahů správcem systému, ale jak se říká, to je jenom záležitost trošky programování. Až budou tyto disky ve větším rozsahu k dispozici, budeme je moci dobře využít.