все таки пришли к необходимости всякого рода кэшей и буферизации, а это как ни крути первейщые кандидаты на источник проблемы при потере питания....

это пока наверное единственная реальная фича которой нету в других ФС и то только потому, что скажем в NTFS концептуально обозначена невозможность восстановления удаленных данных (для требований безопасности, хотя эта фича кажется и не включена по умолчанию)

мда, и не слабо будет еще проводить синхронизацию эта списка в памяти с диском (ведь по сути это будет основная структура ФС которая будет определять ее целостность)

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

вообще кажется не говорил, ты говорил что будешь объединять но не суть важно, важнее то, то дополнительно добавляются операции на оформление этих блоков.

мне просто интересно оценка количества этих самых дополнительных блоков для достижения _необходимого_ уровня восстановимости.
хотя бы примерно ?

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

я работаю с NTFS достаточно давно, чтобы сказать, что я считаю ее достаточно стабильной ФС, которая достаточно быстро и корректно исправляет ошибки в служебной информации файловой структуры - _при_стандартных_режимах_работы_
что я имею в виду ? да я видел, и не раз как она портилась вся, так что даже польз. инфу только часть удавалось спасти, но это происходило только при наличии аппаратных проблем (в основном совсем плохо бывает при ошибках в памяти). я не думаю что какая-то другая _существующая_ ФС смогла бы сделать больше, хотя это и спорное утверждение

Дальнейшее общение, я думаю, имеет смысл, если только ты окончательно и бесповоротно решил таки заделать свою DreamFS и в принципе я готов дальше попытаться выявлять возможные проблемы и заковыки.
Если нет, то я думаю, что здесь так и не нашлось людей, загоревшихся идеей написать такую крутую ФС, как нам с тобой хотелось бы поэтому стоит остановится на этом мажорной ноте
хотя можно наверное еще послать твои идеи каким-нить девелоперам Ext4_Resurrection

зы. пишу и думаю "а много сюда еще текста влезет?"  

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

да не надо так грузиться, все просто! после сбоя ищется последнее состояние системы, в котором файловая система цела. все, что было позже - отменяется. вот и все. нужно лишь два условия:

1. сбой в процессе записи новой информации не должен повреждать старую. реализуется частично нижним уровнем (при неудачной записи данные восстанавливаются за счет избыточных), частично выбором правильного порядка действий
2. сбойную запись (блок, транзакцию) должно быть всегда возможно отличить от успешной. реализуется контрольной суммой: если она неправильная, то явно произошел сбой в процессе записи.

> вообще кажется не говорил, ты говорил что будешь объединять

говорил!!

> мне просто интересно оценка количества этих самых дополнительных блоков для достижения _необходимого_ уровня восстановимости.

1/5..1/10 от общего числа

> ты уверен

я уверен, что команды будет три. но по производительности они будут эквавалентны одной.

а разве в NTFS фича "откат на произвольное время" (скажем, на пол часа) как-то предусмотрена?

достаточно нумеровать транзакции (глобально) и записывать номер последней на диск. с учетом отложенной записи, оверхеда никто не заметит. записывать нужно только для ускорения процесса штатной загрузки файловой системы.

все транзакции, номер которых меньше последнего записанного, заведомо правильны.

не понял...

что такое транзакции служебных данных? у меня такое понятие никак не определено...

> транзакции ведь существуют для того, чтобы выполнять некоторую последовательность операций с уверенностью в том, что она либо завершиться успешно, либо вообще не будет выполнена

ну, у меня они существуют не только и не столько для этого

> есть по сути последовательность операций которая не должна прерываться в середине - она либо должна завершиться, либо ничего не изменить в структуре ФС

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

надо было мне какое-то новое слово придумать, чтобы такой вот путаницы не возникало