GITBOOK-16: No subject

SUMMARY.md

@@ -55,3 +55,7 @@
 
 * [git](develop/git.md)
 * [React](develop/react.md)
+
+## Group 1
+
+* [Файловая система](group-1/failovaya-sistema.md)

group-1/failovaya-sistema.md

@@ -0,0 +1,55 @@
+---
+description: '## Как обеспечивается:'
+---
+
+# Файловая система
+
+* согласованность 
+* атомарность
+* целостность 
+
+В файловой   при записи   данных файла  сохраняет:  метаданные и   сами байты  в память  ( буферизация данных) и только  потом  сбрасывает на диск. 
+
+### Важно: 
+
+Даже, если мы  записываем  4 байта, в память будет загружено  - 4кб  страницу) 
+
+### Оптимальный   алгоритм,   транзакционной записи  данных в файл:
+
+* журналирование данных  ( WAL    ( like Postgres, Kafka  +  номер   версии,  корректности   данных ( валидации,  старые или  новые,  соответствие метаданных и  байтов )   
+* использование   паттернов, для целостности данных   ( 
+  * `ARVR` (Atomic Replace Via Rename) - атомарное обновление содержимого существующего файла через его переименование не всеми гарантируется - при замене старого файла на новый, в файле может оказаться только часть данных
+  * `ACVR` (Atomic Create Via Rename) - атомарное создание нового файла через переименование никем не гарантируется - при переименовании временного файла, новый может не содержать всех данных и быть нулевой длины)  
+* сегментация и  снапшот ( Postgres   -  wal  сегментированный,  что  позволяет   увеличить скорость потоковой  репликации,  ускорить чтение  и восстановление  данных,   увеличивается скорость  записи  в WAL ) 
+*
+
+
+
+#### Пример: 
+
+
+
+Undo лог хранит в себе данные, которые необходимы для _отката_ операций. В случае перезаписи файла, он хранит в себе участки исходного файла, которые мы перезаписываем. Например, если мы хотим записать новые данные (`new_data`) начиная с 10 байта (`start`) длиной в 15 байтов (`length`), то в этот лог будут записаны байты с 10 по 15 из текущего, еще не измененного файла (`old_data`). Алгоритм записи данных будет следующим:
+
+1. `creat("/dir/undo.log")` - Создаем файл undo лога
+2. `write("/dir/undo.log", "[check_sum, start, length, old_data]")` - Записываем в него данные из исходного файла, которые собираемся изменить:
+   * `start` - позиция, с которой собираемся производить запись
+   * `length` - длина перезаписываемого участка
+   * `old_data` - данные исходного файла, которые перезаписываем (не новые, а старые для отката)
+   * `check_sum` - чек-сумма, вычисленная для `start`, `length` и `old_data`
+3. `fsync("/dir/undo.log")` - Сбрасываем данные файла на диск
+4. `fsync("/dir")` - Сбрасываем содержимое директории (теперь undo лог точно на диске)
+5. `write("/dir/data", new_data)` - Записываем новые данные
+6. `fsync("/dir/data")` - Сбрасываем изменения основного файла на диск
+7. `unlink("/dir/undo.log")` - Удаляем undo лог
+8. `fsync("/dir")` - Сбрасываем изменение данных директории на диск (удаление undo лога)
+
+#### Что здесь учли:
+
+* Отказ прямо после создания файла undo лога - в начале идет чек-сумма, с помощью которой можно это обнаружить
+* Переупорядочивание операций записи - чек-сумма для всей записи в undo логе на случай, если операции будут переупорядочены (если изменения большие, то возможно одним `write` не обойтись) или нарушена целостность
+* Отказ перед началом записи данных в сам файл - вызываем `fsync` для файла undo лога и его директории (файл лога точно на диске)
+* Удаление самого файла undo лога - в конце вызываем `fsync` для директории, чтобы undo лог был действительно удален
+
+PS:[https://habr.com/ru/articles/803347/](https://habr.com/ru/articles/803347/)
+