>>Та да. А где POSIX-семантика предусматривает потерю данных? Ткните пальцем в стандарт,
>>что ли.
>>Понимаете ли, надежность приложений НЕ ДОЛЖНА зависеть от типа нижележащей fs, потому
>>что интерфейс - един.
>>Нефиг, проме того, плодить интерфейсы, если нужную семантику для понимающих (скажем, включить
>>delayed allocation для конкретного файла) приложений можно встроить в существующий интерфейс.
>>По дефолту всё должно быть надежно.
>
>Да вы долбанулись - вы сами приказали ФС открыть файл СО СТИРАНИЕМ
>ДАННЫХ. open(name, O_CREAT | O_TRUNC, 0666)

Ой, какой феерический бред. Приведенные флаги - означают, что создается новый файл, и если на его месте что-то уже было, стереть его. Но и только. Это вовсе не означает, что вновь создаваемый файл после этой точки - будет стёрт.

>Поскольку транзакций в POSIX тоже нет, то нет и их комитта. А
>потому ФС имеет полное право проводить с файлом изменения согласно выполняемой
>программе, т.е. стереть данные.

Вы б внимательнее и новость почитали, и маны. В том же open(2) есть флаг открытия файла в синхронном режиме, когда write() не будет возвращаться без реальной записи. А в rename(2) есть вот  такое:

     The rename() system call guarantees that if to already exists, an
     instance of to will always exist, even if the system should crash in the
     middle of the operation.

STANDARDS
     The rename() system call is expected to conform to ISO/IEC 9945-1:1996
     (``POSIX.1'').

Так что та необходимая атомарность и надежность, о которой говорит и Линус - в POSIX есть. Поверх этого можно и транзакционный интерфейс прикрутить, если приложению хочется, но - уже самому себе в юзерлэнде, ядро не обязано.