FS redundancy
https://blog.acolyer.org/2017/03/08/redundancy-does-not-imply-fault-tolerance-analysis-of-distributed-storage-reactions-to-single-errors-and-corruptions/
- File system problems
- 3 contributions: CORDS, study of 8 systems, observations
- FS: media -> firmware -> driver. Problems in any layer
- Block errors and block corruptions
- Ext4 returns error or corrupted data. Btrfs, zfs transform corruption to error.
- Observations:
- systems employ diverse data integrity strategies. checksums (ZK, MongoDB, CockroachDB) vs trust lower system to check integrity problems (RethinkDB + Redis). Inappropriate checksum algorithms (Adler32 for ZK <- a lot of collisions for short strings)
- Faults are undetected very often. When detected -> crash. Redis spread error of aof of the leader. Cassandra. RethinkDB,
- Redundancy is underutilized, single fault can have large cluster-wide effect. Mongo + LogCabin recover from some corruptions by using replicas’ data
- Crush and corruption handling are entangled. Usually crash = corruption in the handling code. RethinkDB find corruption -> rollback last transaction (even if it is not crash, but a ‘read corruption’). Kafka truncate and loses all further data (not fix one corruption). Mongo try to fix corruption but re-applying all the log entries from other hosts (not only 1 corrupted entry)
- Nuances in commonly used distributed protocols can spread corruption or data loss. Kafka node remove all log entries after corrupted entry, and after that might become a leader! When data is corrupted on leader, it is not detected, and is spread on followers.
- btrfs and zfs use checksums, error instead of corrupted read.
IMHO:
- интересно разграничивают crash vs corruption.
- неправильное чтение - отдельный тест, который показывал интересные результаты (RethinkDB rollback)
Паралич Функционального Программиста
https://medium.com/@rulexec/functional-programming-considered-harmful-21485826ad4#.efq3yriu9
- JavaScript - в функциональном стиле
- Путь - генератор имен файлов по пути
- Файл - дескриптор в JS (число). Файлы не подвержены сборщику мусора,
- Закрытие файла (ресурса) - Препятствие попыткам использовать освобожденный ресурс.
- close -> ресурсу сообщение и возвращает “ошибку”. Ресурс после попытки закрытия асинхронно - отвечает об успехе и об “ошибке”
IMHO:
- потекла абстракция JS:
- попытка сделать GC для открытых файлов
- попытка написать менеджер ресурсов
- выводы (сложность написать чтение из файла в функциональном стиле) никак не связана с реальностью, те же проблемы были бы при работе в императивном стиле
- вывод “при работе в функциональном стиле ее сложность возрастает на порядок” взят с потолка (нет в тексте доказательств этого тезиса)