translate more ways for filesystem consistency check and repair slide

Author: Vladimir Kotal

files.tex

@@ -555,89 +555,91 @@
 
 %%%%%
 
-\pdfbookmark[1]{more ways to for ensuring filesystem consistency}{fsconsistency}
+\pdfbookmark[1]{more ways for ensuring filesystem consistency}{fsconsistency}
 
 \begin{slide}
-\sltitle{Další způsoby zajištění konzistence filesystému}
+\sltitle{More ways for ensuring filesystem consistency}
 \setlength{\baselineskip}{0.8\baselineskip}
 \begin{itemize}
 \setlength{\itemsep}{0ex}
-\item tradiční UFS -- synchronní zápis metadat
+\item traditional UFS -- synchronous metadata writes
     \begin{itemize}
     \setlength{\itemsep}{0ex}
-    \item aplikace vytvářející nový soubor čeká na inicializaci inode na
-    disku; tyto operace pracují rychlostí disku a ne rychlostí CPU
-    \item asynchronní zápis ale častěji způsobí nekontistenci metadat
+    \item an application creating new file is waiting till the inode is
+    initialized on disk; these operations are done with disk speed, not CPU
+    speed
+    \item however asynchronous writes more often cause metadata inconsistencies
     \end{itemize}
-\item řešení problémů s nekonzistencí metadat na disku:
+\item solutions to metadata inconsistency problem:
     \begin{itemize}
     \setlength{\itemsep}{0ex}
-    \item \emph{journalling} -- skupina na sobě závislých operací se
-    nejdříve atomicky uloží do žurnálu; při problémech se pak žurnál
-    může ``přehrát''
-    \item bloky metadat se nejdříve zapíší do non-volatile paměti
-    \item \emph{soft-updates} -- sleduje závislosti mezi ukazately
-    na diskové struktury a zapisuje data na disk metodou
-    \emph{write-back} tak, že data na disku jsou vždy konzistentní
-    \item \emph{ZFS} je nový filesystém v Solarisu, který používá
-    \emph{copy-on-write} transakční model
+    \item \emph{journalling} -- one group of operations dependent on each other
+    is written to a journal first; if a problem is encountered the journal can
+    be ``replayed''
+    \item metadata blocks are written to non-volatile memory first
+    \item \emph{soft-updates} -- follows dependencies between pointers to disk
+    structures and writes the data using the \emph{write-back} method so that
+    the data are always consistent on disk.
+    \item \emph{transactions}
     \end{itemize}
 \end{itemize}
 \end{slide}
 
 \begin{itemize}
 \item filesystem \emph{metadata} = inodes, directories, free block
 maps
-\item \emph{ext2} dokonce defaultně používá asynchronní zápis metadat a je při
-použítí synchronního zápisu výrazně pomalejší než UFS
-\item závislé operace jsou například smazání položky z adresáře a smazání
-diskového inode. Pokud by se stalo, že se nejdříve smaže diskový inode a pak
-teprve položka v adresáři, při výpadku mezi těmito dvěmi operacemi vniká
-nekonzistence -- link ukazuje na diskový soubor, který neexistuje. Není
-problém se tomuto vyhnout při synchronním zápisu metadat (víme kdy a co
-zapisujeme, určujeme tedy pořadí zápisu), ale při metodě write-back je již
-nutné řešit závislosti jednotlivých bloků na sebe, protože při klasické
-synchronizaci vyrovnávacích pamětí na disk jádro nezajímá, který blok se
-zapíše dřív a který později.
-\item často jsou bloky na sobě závislé ve smyčce. Soft updates dokáže takovou
-smyčku rozbít tím, že provede \emph{roll-back} a po zápisu pak
-\emph{roll-forward}
-\item výkon soft updates je srovnatelný výkonu UFS filesystému s asynchronním
-zápisem metadat
-\item teoreticky soft updates zaručují, že po rebootu není potřeba použít
-\texttt{fsck}, tj. že filesystém bude v takovém stavu, že je možné nabootovat.
-Je však nutné použít tzv. \emph{background fsck} pro opravy nezávažných chyb
--- to je považováno stále za velkou nevýhodu soft updates zvláště s tím, jak
-rostou velikosti běžně používaných disků. Takovou chybou, která nebrání
-nabootování, ale je nutné ji odstranit je například blok, který je označen
-jako použitý, ale žádný soubor ho nepoužívá.
-\item soft updates nejsou vždy doporučovány pro root filesystém. Problém je
-to, že ztráta metadat na root filesystému (viz 30-ti sekundová perioda zápisu)
-může být výrazně větší hrozbou zde než na \texttt{/usr}, \texttt{/home} atd.
-Další nevýhodou může být i to, že u soft updates mi smazání velkého souboru
-hned neuvolní místo.
-\item příklad: na bezpečnou operaci rename potřebuju při synchronním zápisu
-metadat 4 zápisy -- zvýšení počtu odkazů v inode, vytvoření nové
-a\-dre\-sá\-řo\-vé položky, smazání staré, a opětné snížení počtu odkazů v
-inode. Kdykoli by systém spadnul, nenastane nebezpečná situace. Například 2
-odkazy z adresářů na inode s referenčním počtem 1 je problém, protože po zrušení
-jednoho odkazu to bude vypadat, že soubor je stále na disku, když už byla jeho
-data dávno smazána. Není težké si asi představit, co by to mohlo znamenat v
-případě, že soubor obsahoval opravdu důležitá data -- například zálohu. Opačná
-situace, tj. jeden odkaz na inode s referencí 2 sice také není správná situace,
-ale neohrožuje to možnost filesystém namontovat a normálně používat. V nejhorším
-se stane, že soubor vypadá že již na disku není a přitom stále existuje. U soft
-updates operace rename vytvoří kružnici, protože nejdříve je potřeba zapsat
-zvýšení počtu referencí, pak adresářové bloky a poté snížení referencí. A
-protože zvýšení/snížení se týká stejného inode, tak je při zápisu třeba udělat
-roll-back na (řekněme) 2, zapsat inode na disk, zapsat bloky adresárů a pak
-roll-forward na počet referencí 1. Při této akci je nad inodem držen zámek,
-takže nikdo nenačte starší data. Je jednoduché ukázat, že nelze zapsat žádný z
-těch tří bloků v kružnici tak, jak to je na konci operace rename, že je opravdu
-nutný ten roll-back -- mohli bychom uvažovat, že inode se vlastně nezměnil a
-není třeba řešit zda se může/nemůže zapsat; zápis nového adresářového odkazu bez
-zvýšení počtu odkazů v inodu by nás totiž mohl dostat přesně do situace, která
-je popsána o pár řádků výše.
+\item \emph{ext2} uses asynchronous metadata writes even by default and when
+in synchronous mode it is much slower to UFS.
+\item Dependent operations are for example deleting an item from directory and
+deleting disk inode. If the inode is deleted first and then the directory entry
+then if there is outage between these two operations then inonsistency follows
+-- the link points to disk file that does not exist. It is not a problem to
+avoid this when using synchronous metadata writes (we know when a what is being
+written, the ordering of writes is therefore under our control) however when
+using the write-back method it is necessary to solve dependencies of the blocks
+because with classic synchronization of cache buffers the kernel is not
+interested in which blocks is written first.
+\item Often the block dependencies for a cycle. Soft updates can recognize sych
+cycle and break it by performing \emph{roll-back} and after the write is done it
+performs \emph{roll-forward}.
+\item The soft updates performance is comparable to that of UFS with
+asynchronous metadata writes.
+\item Theoreticall soft updates guratantee that it is not necessary to use
+\texttt{fsck} after the reboot, i.e. that the filesystem is in bootable state.
+It is however necessary to use so called \emph{background fsck} for correcting
+non-grave errors -- this is considered to be one of the big drawbacks of soft
+updates, especially given how sizes of disks grow over time. Example of an error
+that does not block booting would be a block that is marked as used however is
+not used by any file.
+\item soft updates are not always recommended for the root filesystem.
+The problem is that metadata loss on root file system (see the 30 second
+period of writes) can be more dangerous than in \texttt{/usr}, \texttt{/home}
+etc. Another disadvantage is that after deleting huge file soft updates do not
+free up the space immediately.
+\item Example: it is necessary 4 writes for secure rename operations when using
+synchronous writes -- increase the number of references in inode, create new
+directory entry, delete old entry, decrease the number of references.
+If a system goes down between each of these a dangerous situation will ensue.
+For example 2 references from directories to inode with reference count of 1 is
+a problem because after deleting one of the references it would look like the
+file is still on disk, when its data has been deleted already.
+It is not hard to imagine what would it mean if the file contained important
+data -- e.g. backup.
+Opposite situation, i.e. one reference to inode with reference count equal 2 is
+not correction situation either however it does not pose a threat to mount the
+filesystem and normally use it. In the worst case the file looks as it is no
+longer on disk while it still exists. For soft updates the rename operation will
+form a cycle because it is necessary to write the increased reference count
+first, then directory blocks and then decreased reference. And because
+increase/decrease is done for the same inode, then for the write it is necessary
+to do roll-back to (say) 2, write inode to disk, write directory blocks and then
+roll-forward to reference of 1. During this operation a lock is held for the
+inode so that no one will read older data. It is simple to show that it is not
+possible to write any of these 3 blocks in a cycle to match the end of the
+rename operation so that the roll-back is truly needed -- we could consider that
+the inode did not really change and it is not necessary to decide whether to
+write it or not; the write of directory reference without increasing reference
+count in the inode could get us into situation which is descibed above.
 \end{itemize}
 
 \endinput