pokud vypnu počítač ihned po úpravě a uložení souboru, budou mé změny s největší pravděpodobností ztraceny?
Mohou být. Neřekl bych „s největší pravděpodobností“, ale pravděpodobnost závisí na spoustě věcí.
Snadný způsob, jak zvýšit výkon zápisu souborů, spočívá v tom, že operační systém uloží data do mezipaměti, řekne (zalže) aplikaci, kterou zápis prošel, a zápis skutečně provede později. To je zvláště užitečné, pokud současně probíhá jiná disková aktivita:OS může upřednostňovat čtení a zapisovat později. Může také zcela odstranit potřebu skutečného zápisu, např. v případě, kdy je dočasný soubor odstraněn rychle poté.
Problém s mezipamětí je výraznější, pokud je úložiště pomalé. Kopírování souborů z rychlého disku SSD na pomalou jednotku USB bude pravděpodobně vyžadovat hodně ukládání do mezipaměti, protože jednotka USB prostě nemůže držet krok. Ale vaše cp příkaz se vrací rychleji, takže můžete pokračovat v práci, případně i upravovat soubory, které byly právě zkopírovány.
Ukládání do mezipaměti má samozřejmě nevýhodu, kterou si všimnete, že některá data mohou být ztracena, než se skutečně uloží. Uživatel bude zklamán, pokud mu jeho editor řekl, že zápis byl úspěšný, ale soubor ve skutečnosti nebyl na disku. Proto je tu fsync() systémové volání, které se má vrátit až poté, co soubor skutečně narazí na disk. Váš editor to může použít k tomu, aby se ujistil, že data jsou v pořádku, než oznámí uživateli, že zápis byl úspěšný.
Řekl jsem "má se to", protože samotná jednotka může říct stejné lži OS a říci, že zápis je dokončen, zatímco soubor skutečně existuje pouze v nestálé mezipaměti pro zápis v rámci jednotky. V závislosti na jednotce to nemusí být možné obejít.
Kromě fsync() , existují také sync() a syncfs() systémová volání, která žádají systém, aby se ujistil, že všechny celosystémové zápisy nebo všechny zápisy na konkrétním souborovém systému zasáhly disk. Nástroj sync lze použít k jejich volání.
Pak je tu také O_DIRECT příznak na open() , který se má "pokusit minimalizovat efekty mezipaměti I/O do az tohoto souboru." Odstranění mezipaměti snižuje výkon, takže to většinou využívají aplikace (databáze), které si provádějí vlastní ukládání do mezipaměti a chtějí to mít pod kontrolou.(O_DIRECT není bez problémů, komentáře o něm v manuálové stránce jsou poněkud zábavné.)
Co se stane při výpadku napájení, závisí také na souborovém systému. Neměli byste se starat pouze o data souboru, ale také o metadata souborového systému. Mít data souboru na disku není moc užitečné, pokud je nemůžete najít. Pouhé rozšíření souboru na větší velikost bude vyžadovat alokaci nových datových bloků a ty je třeba někde označit.
Jak se souborový systém vypořádává se změnami metadat a pořadí mezi metadaty a zápisy dat, se hodně liší. Např. s ext4 , pokud nastavíte příznak připojení data=journal , pak všechny zápisy – dokonce i zápisy dat – procházejí žurnálem a měly by být spíše bezpečné. To také znamená, že jsou napsány dvakrát, takže výkon klesá. Výchozí možnosti se snaží seřadit zápisy tak, aby data byla na disku před aktualizací metadat. Jiné možnosti nebo jiný souborový systém může být lepší nebo horší; O komplexní studii se ani nebudu pokoušet.
V praxi by se na málo zatíženém systému měl soubor dostat na disk během několika sekund. Pokud máte co do činění s vyměnitelným úložištěm, před vytažením média odpojte souborový systém, abyste se ujistili, že jsou data skutečně odeslána na jednotku a neprobíhá žádná další činnost. (Nebo to za vás udělá prostředí GUI.)
Existuje extrémně jednoduchý způsob, jak dokázat, že to nemůže je pravda, že úpravy souborů se vždy ukládají přímo na disk, zejména skutečnost, že existují souborové systémy, které nejsou na prvním místě zálohovány diskem . Pokud souborový systém nemá disk na prvním místě, pak to nemůže zapsat změny na disk, kdykoli .
Některé příklady jsou:
tmpfs, souborový systém, který existuje pouze v paměti RAM (nebo přesněji ve vyrovnávací paměti)ramfs, souborový systém, který existuje pouze v RAM- jakýkoli síťový souborový systém (NFS, CIFS/SMB, AFS, AFP, …)
- jakýkoli virtuální souborový systém (
sysfs,procfs,devfs,shmfs, …)
Ale ani pro souborové systémy zálohované na disku to obvykle neplatí. Stránka Jak poškodit databázi SQLite obsahuje kapitolu nazvanou Selhání synchronizace který popisuje mnoho různých způsobů, jakými mohou zápisy (v tomto případě potvrzení do databáze SQLite) selhat na disk. SQLite má také bílou knihu vysvětlující mnoho obručí, kterými musíte proskočit, abyste zaručili Atomový závazek v SQLite . (Všimněte si, že Atomic Write je mnohem těžší než jen problém Psát , ale zápis na disk je samozřejmě dílčím problémem atomového zápisu a o tomto problému se také můžete hodně dozvědět z tohoto článku.) Tento článek obsahuje sekci Věci, které se mohou pokazit která obsahuje podsekci o Neúplných vyprázdněních disku které uvádějí některé příklady jemných složitostí, které mohou bránit zápisu na disk (například řadič HDD hlásí, že zapsal na disk, i když tomu tak není – ano, existují výrobci pevných disků, kteří to dělají a být dokonce legální podle specifikace ATA, protože je v tomto ohledu formulována nejednoznačně).
Je pravda, že většina operačních systémů, včetně Unixu, Linuxu a Windows, používá pro urychlení operací mezipaměť pro zápis. To znamená, že vypnutí počítače bez jeho vypnutí je špatný nápad a může vést ke ztrátě dat. Totéž platí, pokud odeberete úložiště USB dříve, než bude připraveno k odebrání.
Většina systémů také nabízí možnost synchronního zápisu. To znamená, že data budou na disku dříve, než aplikace obdrží potvrzení o úspěchu, za cenu toho, že budou pomalejší.
Stručně řečeno, existuje důvod, proč byste měli správně vypnout počítač a řádně připravit úložiště USB k odebrání.