OSDev

Ну вот в ожидании конкретных предложений люди пока прикручивают к osdev'у нейросети и SQLFS. Еще можно сознание расширять, но за такое Роскомнадзор забанить может.

Для систем, которые использую на работе и дома вполне хватает надежности NTFS, но вот нежурналируемые системы типа FAT использовать для хранения ценной информации я бы не стал.

А вот от файловой системы, которую гарантированно без сбоев можно выключать выдергиванием питания из розетки я бы не отказался. Ну, при условии, что потеря производительности будет не в разы отличаться, как при отключении кэша записи.

ну хоть программирование затронуть бы, ОС состоит из драйверов и программной начинки,
вторую часть добавить бы.

1. "Остаточное" питание в ПЭВМ всё таки используется - им гарантируется в большинстве современных жестких дисков что сектор в любом случае будет записан полностью. У старых этого гарантировать было нельзя - часть сектора могла быть записана часть нет. Для себя я решил, что данной возможности не существует благо она не слишком необходима.

2. За всё надо платить - если Вы выдергиваете питание, то существующие транзакции не закрываются надлежащим образом и надо восстанавливать. Что при этом потеряется - вопрос открытый т.к. для нормальной работы современные файловые системы, которые по структуре как правило являются оптимизированными для записи применяют агрессивное кэширование а точки консистентности у них обычно делаются через 30 секунд. Я считаю, что такой способ завершения работы - аварийный и если он происходит, то пользователь готов к небольшим потерям. Иначе - надо писать сразу и данные и метаданные и после этого возвращать подтверждение - это ухудшит производительность.

3. Гугл на своих серверах как я читал применяет ext 3 или 4 без журналирования! Так быстрее, а данные всё равно существуют в нескольких копиях. Отсюда ещё один вывод - отказоустойчивость может достигаться разными путями. Лично я считаю что для распределенной файловой системы общего назначения система восстановления нужна хотябы потому, что она нужна для журнала транзакций.

4. Про NTFS мне больше всего интересно её будущее. Уже есть ReFS, который не включает (и кое что не понятно как может включить в будущем) многие фичи NTFS. Например как туда альтернативные потоки данных прикручивать? Очевидно, что ОС от MS надо поддерживать, но вот какие возможности?

С другой стороны - я ориентируюсь на клиентов NFS4.1 (т.е. фактически хочу сделать сервер NFS4.1 со всеми его возможностями, но на своем движке хранения данных а не на какой-нибудь файловой системе), это "ограничивает" сверху возможности т.к. любой оверинжиниринг в файловой системе будет через стандарт просто не виден потребителям . В этом стандарте много сделано для виндов, но с другой стороны - даже ACL в нем не полностью совместимый, хотя при разработке имели в виду именно винды. В общем вопросы-вопросы.

Вот с этим категорически согласен. Сейчас широко используется сборка мусора в языках, технология затратная по аппаратным ресурсам, но экономит время разработки. Раньше она была не так распространена. Интересно, куда дальше пойдёт развитие?
SQLFS и прочие подобные идеи нестандартных FS уже была попытка внедрить. Что то пошло не так, но когда нибудь и они станут стандартом, надеюсь. Спасибо кстати за ссылки на обсуждение на freepascal.ru и про LSMT.
Несмотря на то, что LSMT кажется просто урезанным подобием полноценных систем хранения данных, сам подход демонстрирует направление развития.



Непонятно только какой отсюда вывод: нужна ли или нет ещё одна дос?



Ну правильно, надо же рекурсивно пройтись по всем файлам, для каждого освободить цепочку кластеров, для каждой директории тоже освободить цепчку кластеров. Но разве есть ФС, которые сделают это быстрее? И если есть - то почему они быстрее работают?



А что предлагаешь затронуть по программированию? Из последних широковнедряемых технологий это сборка мусора и элементы функционального программирования. ООП уже можно не считать. Программирование стоит (видимо, ожидая пока квалификация кодеров поднимется в массе своей, чтобы можно было двигаться дальше), обсуждать там практически нечего, имхо. Только фасады меняются в соответствии с тактикой огня и движения. Хотя двигаться ещё есть куда.

1. Надо мыслить шире: внедряются не базы данных а технологии баз данных т.к. почти всё в файловых системах можно свести к key-value хранилищу. Так сделано в ZFS, насколько я понимаю в ReFS и многих других.

2. LSMT это способ организации key-value хранилища с быстрой вставкий и доступом к новым данным, но медленным доступом - к историческим данным. Есть всякие патентованные версии этого способа хранения, которые ускоряют и оптимизируют процесс размещения данных.

3. FAT ковыряет каждую ссылку на блок при удалении. Если выделять память экстентами - будет быстрее, а если стирать не сразу а в фоне, то это не только даст возможность восстанавливать недавно стертое, но и ускорить стирание а заодно выполнять дефрагментацию.

4. Кстати во многих системах есть сабаллокация блоков, которые изначально выделяются крупными кусками. Это эффективно для многих современных приложений - например для хостинга виртуальных машин у которых крупные файлы виртуальных дисков.