Důvěřujeme integritě dat získaných ze swapu, protože hardware úložiště má kontrolní součty, CRC a podobně.
V jednom z výše uvedených komentářů říkáte:
pravda, ale nechrání to před převrácením bitů mimo samotný disk
"It" zde znamená kontrolní součty disku.
To je pravda, ale SATA používá 32bitové CRC pro příkazy a data. Máte tedy šanci 1 ku 4 miliardám nezjistitelného poškození dat mezi diskem a řadičem SATA. To znamená, že nepřetržitý zdroj chyb by mohl způsobit chybu tak často, jako každých 125 MiB přenesených, ale vzácný, náhodný zdroj chyb, jako je kosmické záření, by způsoboval nedetekovatelné chyby s mizivě malou rychlostí.
Uvědomte si také, že pokud máte zdroj, který způsobí nezjištěnou chybu rychlostí blízkou jedné na 125 MiB přenesených, bude výkon hrozný kvůli vysokému počtu zjištěných chyby vyžadující opakovaný přenos. Sledování a protokolování vás pravděpodobně na problém včas upozorní, aby nedošlo k nezjištěnému poškození.
Pokud jde o kontrolní součty paměťového média, každý SATA (a před ním PATA) disk používá nějaký druh kontrolních součtů pro jednotlivé sektory. Jednou z charakteristických vlastností „podnikových“ pevných disků jsou větší sektory chráněné dalšími funkcemi integrity dat, což výrazně snižuje možnost neodhalené chyby.
Bez těchto opatření by rezervní sektor na každém pevném disku neměl smysl:samotný disk by nedokázal detekovat vadný sektor, takže by nikdy nemohl vyměnit nové sektory.
V dalším komentáři se ptáte:
pokud je SATA tak důvěryhodné, proč existují souborové systémy s kontrolním součtem jako ZFS, btrfs, ReFS?
Obecně řečeno, nepožadujeme od swapu dlouhodobé ukládání dat. Limit úložiště ve swapu je doba provozuschopnosti systému a většina dat ve swapu nevydrží tak dlouho, protože většina dat, která prochází systémem virtuální paměti vašeho systému, patří k procesům s mnohem kratší životností.
Navíc se doba provozu v průběhu let obecně zkrátila, což se zvýšenou frekvencí jádra a libc aktualizace, virtualizace, cloudové architektury atd.
Navíc většina dat ve swapu se v dobře spravovaném systému přirozeně nepoužívá, protože se nevyčerpává z hlavní RAM. Jediné, co v takovém systému skončí ve swapu, jsou stránky, které program nepoužívá často, pokud vůbec. To je častější, než byste mohli hádat. Většina dynamických knihoven, které vaše programy propojují, aby v nich byly rutiny, které váš program nepoužívá, ale musely být načteny do RAM dynamickým linkerem. Když operační systém zjistí, že nepoužíváte veškerý text programu v knihovně, zamění jej a uvolní místo pro kód a data, kterými vaše programy jsou použitím. Pokud jsou takto vyměněné paměťové stránky poškozeny, kdo by to kdy věděl?
Porovnejte to s ZFS, kde očekáváme, že data budou trvale a trvale uložena, takže vydrží nejen po aktuální době provozu systému, ale také po dobu životnosti jednotlivých úložných zařízení, která úložný systém tvoří. ZFS a podobně řeší problém s časovým měřítkem zhruba o dva řády delším, než je problém řešený swapem. Proto máme mnohem vyšší požadavky na detekci korupce pro ZFS než pro Linux swap.
ZFS a podobně se zde liší od swapu v dalším klíčovém způsobu:nezaměňujeme souborové systémy RAID dohromady. Když se na jednom počítači používá více odkládacích zařízení, jedná se o schéma JBOD, nikoli jako RAID-0 nebo vyšší. (např. schéma zřetězených odkládacích souborů macOS, Linux swapon , atd.) Vzhledem k tomu, že odkládací zařízení jsou nezávislá, spíše než na sobě závislá jako u RAID, nepotřebujeme rozsáhlé kontrolní součty, protože výměna odkládacího zařízení nezahrnuje hledání dat na jiných vzájemně závislých odkládacích zařízeních, která by měla jít na náhradní zařízení. . Z hlediska ZFS nevyměňujeme zařízení z nadbytečných kopií na jiných úložných zařízeních.
To vše znamená, že musíte používat spolehlivé odkládací zařízení. Jednou jsem použil externí USB HDD za 20 dolarů k záchraně churavějícího fondu ZFS, jen abych zjistil, že kryt byl sám o sobě nespolehlivý a do procesu vnášel vlastní chyby. Silný kontrolní součet ZFS mě tady zachránil. Takové kavalírské zacházení s paměťovými médii s odkládacím souborem vám neprojde. Pokud swap zařízení umírá a blíží se tak nejhoršímu případu, kdy by každých 125 MiB přenesených mohlo vnést nezjistitelnou chybu, musíte jej jednoduše vyměnit, ASAP.
Celkový pocit paranoie v této otázce přechází na příklad problému byzantských generálů. Přečtěte si to, zamyslete se nad datem z roku 1982 v akademickém článku popisujícím tento problém ve světě informatiky a pak se rozhodněte, zda v roce 2019 máte nové myšlenky, jak tento problém doplnit. A pokud ne, pak možná právě použijete technologie navržená třemi desetiletími absolventů CS, kteří všichni vědí o problému byzantských generálů.
Toto je dobře prošlapaná půda. Pravděpodobně nemůžete přijít s nápadem, námitkou nebo řešením, které ještě nebylo k smrti prodiskutováno v odborných časopisech.
SATA rozhodně není úplně spolehlivá, ale pokud se nechystáte vstoupit do akademické sféry nebo do jednoho z vývojových týmů jádra, nebudete v pozici, kdy byste mohli materiálně přispívat k současnému stavu techniky. Tyto problémy jsou již dobře v rukou, jak jste již poznamenali:ZFS, btrfs, ReFS... Jako uživatel OS prostě musíte věřit, že tvůrci OS se o tyto problémy postarají za vás, protože také vědí o byzantských generálech.
V současné době není praktické umístit svůj odkládací soubor na ZFS nebo Btrfs, ale pokud vás výše uvedené neuklidňuje, můžete jej umístit alespoň na xfs nebo ext4. To by bylo lepší než používat vyhrazený odkládací oddíl.
Výměna má??? <--- to je moje otázka
Swap stále není chráněn v Linuxu (ale viz UPD).
No, samozřejmě existuje ZFS na Linuxu, který je schopen být odkládacím úložištěm, ale za určitých okolností stále existuje uzamčení – čímž je tato možnost účinně zrušena.
Btrfs stále neumí pracovat se swapovacími soubory. Zmiňují možné použití zpětné smyčky, i když se uvádí, že má slabý výkon. Není jasné, že by to Linux 5 mohl mít konečně(?)…
Záplaty na ochranu konvenčního swapu pomocí kontrolních součtů se nedostaly do hlavního proudu.
Takže celkově:ne. Linux tam má stále mezeru.
UPD. :Jak zdůrazňuje @sourcejedi, existuje takový nástroj jako dm-integrity. Linuxové jádro od verze 4.12 získalo cíl mapovače zařízení, který lze použít pro poskytování kontrolních součtů všem obecným blokovým zařízením a ty, které jsou určeny pro swap, nejsou výjimkou. Nástroje nejsou široce začleněny do hlavních distribucí a většina z nich nemá žádnou podporu v subsystému udev, ale nakonec by se to mělo změnit. Při spárování s poskytovatelem redundance, řekněme vloženým do MD alias Linux Software RAID, by mělo být možné nejen detekovat bit rot, ale také přesměrovat I/O požadavek na zdravá data, protože integrita dm by naznačovala, že existuje problém a MD by to měl vyřešit.
integrita dm
Viz:Documentation/device-mapper/dm-integrity.txt
dm-integrity by se normálně používal v režimu žurnálování. V případě swapu se můžete obejít bez žurnálování. To by mohlo výrazně snížit režii výkonu. Nejsem si jistý, zda byste při každém spouštění museli přeformátovat oddíl swap-over-integrity, abyste se vyhnuli zachycení chyb po nečistém vypnutí.
V úvodním oznámení dm-integrity , autor místo toho uvádí preferenci "ochrany integrity dat na vyšší úrovni". V případě swapu by to otevřelo možnost ukládání kontrolních součtů do RAM. Tato možnost by však vyžadovala netriviální úpravy aktuálního odkládacího kódu a zvýšila by využití paměti. (Aktuální kód sleduje swap efektivně pomocí oblastí, nikoli jednotlivých stránek / sektorů).
DIF/DIX?
Podpora DIX byla přidána společností Oracle v Linuxu 2.6.27 (2008).
Poskytuje použití DIX ucelenou integritu?
Můžete se poradit se svým prodejcem. Nevím, jak byste mohli poznat, zda o tom lžou.
DIX je vyžadován k ochraně dat v letu mezi OS (operačním systémem) a HBA .
DIF sám o sobě zvyšuje ochranu dat v letu mezi HBA a úložným zařízením . (Viz také:prezentace s několika údaji o rozdílech v chybovosti).
Právě proto, že kontrolní součet v poli stráže je standardizován, je technicky možné implementovat příkazy DIX bez poskytnutí jakýchkoli ochrana dat v klidu. Stačí nechat HBA (nebo úložné zařízení) obnovit kontrolní součet v době čtení. Tento výhled byl zcela jasný díky původnímu projektu DIX.
- DIF/DIX jsou ortogonální na logické blokové kontrolní součty
- Stále vás milujeme, btrfs!
- K detekci poškozených dat se používají chyby kontrolního součtu logického bloku
- Detekce probíhá v čase READ
- ... což může být o měsíce později, původní vyrovnávací paměť je ztracena
- Jakékoli nadbytečné kopie mohou být také špatné, pokud byla původní vyrovnávací paměť zkomolená
- DIF/DIX jsou o proaktivním předcházení korupci
- Především zabránění ukládání špatných dat na disk
- ... a zjištění problémů před vymazáním původní vyrovnávací paměti z paměti
-- lpc08-data-integrity.pdf z oss.oracle.com
Jeden z jejich prvních příspěvků o DIX zmiňuje možnost použití DIX mezi OS a HBA, i když jednotka nepodporuje DIF.
Úplná lživost je relativně nepravděpodobná v „podnikových“ kontextech, kde se v současnosti používá DIX; lidé by si toho všimli. Také DIF byl založen na existujícím hardwaru, který mohl být formátován s 520-bajtovými sektory. Protokol pro použití DIF údajně vyžaduje, abyste disk nejprve přeformátovali, viz kupř. sg_format příkaz.
Pravděpodobnější je implementace, která nedodržuje skutečný princip end-to-end. Abych uvedl jeden příklad, je zmíněn dodavatel, který podporuje slabší možnost kontrolního součtu pro DIX pro úsporu cyklů CPU, která je pak nahrazena silnějším kontrolním součtem níže v zásobníku. To je užitečné, ale nejedná se o úplnou ochranu mezi koncovými body.
Alternativně by operační systém mohl generovat své vlastní kontrolní součty a ukládat je do prostoru tagů aplikace. V současném Linuxu (v4.20) však toto není podporováno. Komentář napsaný v roce 2014 naznačuje, že by to mohlo být způsobeno tím, že „velmi málo úložných zařízení skutečně umožňuje použití prostoru tagů aplikace“. (Nejsem si jistý, zda se to týká samotného úložného zařízení, HBA nebo obojího).
Jaký druh zařízení DIX je k dispozici, která fungují s Linuxem?
Oddělení vyrovnávacích pamětí dat a integritních metadat a také výběr v kontrolních součtech se nazývá Data IntegrityExtensions [DIX]. Protože tato rozšíření jsou mimo rozsah protokolových bodů (T10, T13), Oracle a jeho partneři se je snaží standardizovat v rámci Storage Networking Industry Association.
-- v4.20/Documentation/block/data-integrity.txt
Wikipedia mi říká, že DIF je standardizován v NVMe 1.2.1. U SCSI HBA se zdá být trochu obtížné to určit, pokud nemáme standard, na který bychom mohli poukázat. V tuto chvíli by mohlo být nejpřesnější mluvit o podpoře "Linux DIX" :-). K dispozici jsou zařízení:
SCSI T10 DIF/DIX [sic] je plně podporován v Red Hat Enterprise Linux 7.4 za předpokladu, že jej výrobce hardwaru kvalifikoval a poskytuje plnou podporu pro konkrétní konfiguraci HBA a úložného pole. DIF/DIX není podporován v jiných konfiguracích, není podporován pro použití na spouštěcím zařízení a není podporován na virtualizovaných hostech.
V současné době je známo, že tuto podporu poskytují následující dodavatelé...
-- Poznámky k verzi RHEL 7.5, kapitola 16. Úložiště
Veškerý hardware zmíněný v poznámkách k vydání RHEL 7.5 je Fibre Channel.
Tento trh neznám. Zdá se, že DIX by se v budoucnu mohl stát více dostupnými na serverech. Neznám žádný důvod, proč by se stal dostupným pro spotřebitelské SATA disky - pokud vím, neexistuje ani de-facto standard pro formát příkazů. Zajímalo by mě, jestli bude k dispozici více na NVMe.