> Не важно какая фс и не важно какая база.не скажите - например из ФС - vfat vs NTFS
> Или вы хотите сказать, что существуют неуязвимые к подобным ситуациям файловые системы или базы данных?
ну почти (если брать во внимание что "неубиваемых" решений нет в природе)
> Или это уже продумано и делается без лишнего вмешательства?
... именно так - как Вам уже сказали ранее - гуглим на тему журналируемых файловых систем и журналов транзакций в БД. Все вопросы, которые Вы задаете - уже давным-давно (в той или иной степени) решены. Основной метод - журналируемые транзакции - т.е. "документируем" любое действие, затрагивающее данные (не важно что это - ФС или БД). И только после успешного завершения - убираем из журнала запись. Соответственно, если при старте ОС или БД мы находим незавершенные транзакции - то выполняем процесс "отката" на старые данные.
Да, все это приводит к снижению производительности.
Да, все это (как правило) может быть либо "тонко" настроенно, либо вообще отключено.
Да (ответ на первую цитату) - до сих пор можно найти ФС и БД у которых нет журналирования ;) Вот только они либо "мохнатых" времен, либо специфичны.
Нет, используя у себя на десктопе какой-нит линукс - нужно очень постараться, что-бы выбрать не журналируемую ФС.
Или Вас "беспокоит" что Вам ничего не говорят? - помучайте упорно ту-же десктопную Убунту - поймаете момент, когда она Вас проинформирует о проверке диска. Или Вы жаждете что-бы у Вас непременно спросили - "а будем или нет ?" - смысл? - и так понятно, что если процесс записи был прерван некорректно - то необходимо проверить журнал (может быть откатиться) и выполнить проверку ФС... С БД - ситуация практически аналогична ;)
И "таки-ДА", на стыке журналируемой ФС и БД (да еще и на каком-нить RAID) - можно поймать "очень забавный" процесс реанимации после аварийного отключения питания :)