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

можно еще вспомнить что в современных HDD (а уж тем более в SCSI & SAS) контролерах есть свой кэш - часто на десятки мегабайт.
Поэтому выполнение операции journal commit - нефига не гарантирует что данные окажутся на поверхности (persistent storage).
Поэтому без fsync - вопрос о непротиворечивости файла, вещь достаточно странная,
Даже и с fsync - не сильно лучше. Опишу ситуацию.

создали очень много каталогов в нем сделали файл и туда записали.
после чего вызвали fsync.
Как вы думаете - закомитятся на диск все созданые каталоги? Да? не угадали.
согластно man fsync - это не делается, согластно POSIX - остается на усмотрение разрабочиков FS и системы.
>>>>>

       Calling  fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk.  For that an explicit fsync() on
       a file descriptor for the directory is also needed.
>>>>>>

Да, сейчас ext3 по fsync - выполняет принудительный комит транзакции, который скидывает обновленя data + metadata для всех файлов. Но это скорее особенность FS чем требуемое по стандарту поведение.