Исходное сообщение
"Проблемы с потерей данных на Ext4 разделах в тестовой версии..." Отправлено User294, 13-Мрт-09 15:51
>здесь же нет ни начала тразакции, ни сэйвпоинт (будущий патч - отдалённый >аналог), ни коммитов с ролбеками... Да, я и не спорил - большей части ФС глубоко положить на состояние файла после краха.Они пекутся только о корректности метаданных.При том понятие корректности определено очень вольно - дескать непротиворечивое состояние ну и хватит с нас. Я для себя считаю что приведение файла в какое-то вменяемое состояние - это тоже часть вопроса о корректности метаданных. На мое имхо в идеале должно быть просрано лишь то что не успело физически слиться из кеша на диск и не более того а слив должен происходить при первой возможности, а уж close файла == форсирование слива этого файла на диск ASAP.А не держание его в кеше 150 секунд в надежде что он прое..тся.Выигрыш окажется небольшой (ext3 и так по части фрагментации не особо проблемный) а вот сколько при удобном случае просрется файлов при записи всякой мелочи за 150 секунд кеширование - понятно и дебилу.За 150 секунд много навалить можно.И все это отправится в случае краха в /dev/null.Как-то стремно такие ФС юзать - всех програмеров не построишь а просирать столько данных как-то не с руки. >поэтому либо ПО следит за своей "транзакцией" сама, либо не обижается. Если с одной ФС все работает а с другой сыпется ко всем чертям, затрудняюсь назвать это плюсом ФС.Как ни крути.