>>233 のリンク先にこんなのがありますね。

http://www.dd.iij4u.or.jp/~okuyamak/Documents/NetworkFileSystem.Tune.4.html より引用:

File System は、実は、順序による結果の一意決定性の保証をしなくても File System と
して動作するものを作ることができる。 たとえば、2つの process がほぼ同時に write() と
chmod() を リクエストしてきたとしよう。 一応、順序的には『write→chmod』だとする。

この場合、File System は、
「んー。なんかこの write、時間がかかりそうだな。 先に chmod やるか」
と言って、内部で順序を入れ替えてしまっても、 実は バレナイ 。 ばれないということは
(公平性には欠けるかも知れないが)、 File System の実装としては「あり」だと言うことになる。

しかし、write() と chmod() の間の時間が十分に離れていれば、 そしてこの間にこれ以外の
リクエストがいっさい来なければ、 write() と chmod() はこの順序通りに実行される。

仮に、同一のファイルに対する write() 並びに chmod() で、 しかも chmod() されると
write() が実行できなくなるような場合、 外部から観察した場合のリクエスト順序 と
内部でのリクエスト順序 が一致しなくなる。 しかも、常に一定の結果になれば良いのだが、
その保証が無い場合、journal を利用しても結果が再現できなくなる。 上の例だと、
wirte と chmod が十分時間間隔を開けて到着したので write->chmod の順で
ファイルシステムに反映した結果を client に返したのだが、 この直後に system down
を起こしたとしよう。 journal を実行する際には write と chmod は十分短い間隔で
要求されるので、 chmod->write の順で実行してしまったら、 同じ結果を得ることはできない。