можно ли надёжно записать на диск?

>Но неконсистентности данных не будет. Все записи сериализуются с помощью i_mutex. После взятия i_mutex данные из кэша будут записаны, затем будет выполнен write/O_DIRECT запрос, затем отпущен i_mutex.

Извиняюсь, проглючил. Естественно, ничего лишнего не будет записано. Будут записаны данные от write/O_DIRECT и на выходе прибит неконсистентный кэш, соответствующий записанной области.

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

>>Я считаю что самая большая проблема современных гну-не-юниксов это слабая детерминированность поведения и куча deprecated механизмов.

fixed, ftgj )

>Я считаю что самая большая проблема современных юниксов это слабая детерминированность поведения и куча deprecated механизмов.

В какой-нибудь винде не намного лучше. ;)

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

А какие практические выводы, для программиста? Правильно - никаких. Это как раз из тех ошибок, о которых программе беспокоиться не следует.

/me .oO( ахренеть, уже и direct IO приплели )

А если оно может, но в некоторых областях файла - не может?

Если где-то не может то пусть возвращает ошибку.

Один процесс начал IO с O_DIRECT а другой сделал truncate

Можно сделать так чтобы truncate возвращал ошибку.

Идея простая: O_DIRECT и обычное IO это два разных типа io, смешивать их нельзя. Типа как нельзя смешивать malloc, free, new и delete.

Иначе реализация усложнится до ужаса и будет куча проблем(что мы и имеем). Keep it simple.

винде не намного лучше

в винде вообще пи*дец, не удивлюсь если шиндовс семёрочка сможет запустить код от win3.11. Сколько из-за этого проблем можно почитать в любом блоге по девелопменту под винду.