「Ext3のコミット間隔を当てにしたアプリケーションは、Ext4でデータロスの恐れあり」記事へのコメント

Ubuntu関係なくね？

[Anonymous Coward]

Ubuntuのext4でのみ問題が起こるようにも読める文章ですが、
カーネルの問題であって基本的にディストリビューションは関係ないですよね？
(もちろん独自にパッチをバックポート、とかはあるでしょうが)

本家記事は元のバグレポートがUbuntuに対してなされてるのがわかるので意味が通るんですが
こっちでは何が何やら、ミスリードチックです。

Re:

[Anonymous Coward]

Ext4の問題でも、Ext3のコミット間隔を当てにしたアプリケーションの問題でもなく、Linuxカーネルの問題……ってことですよね？
何のことなのか訳分からなくてLinux環境ではファイルシステムを意識してソフト開発しないといけないのかなんて思ってました。

Re:

[Anonymous Coward]

Ext3のコミット間隔を当てにしたアプリケーションの問題ですよ。

Re:

[Anonymous Coward]

バグ報告や本家を読んでもイマイチ分からないのですが、逆にコミット間隔を当てにするにはどういったコードを書けば良いのでしょうね。コミット間隔が5秒だからってアプリケーションで何をどうするんでしょうか。
突然のシステムダウンから復帰したときに、色んなファイルがゼロバイトになる現象のようなんですど、複数のファイルがごっそりゼロバイトになることに未対応であるアプリがあるってだけなんじゃないかと。

Re:

[BonTf (8325)]

要はPOSIXで制定されている以上の事を求めるプログラマ多すぎ、というのが結論。
Ext3の挙動が標準であると思い込んでアプリケーション書いていたら、その挙動はExt3固有で POSIXにはそんなこと書いてなかった。
それで、Ext4じゃその挙動が変わっちゃったという話みたい。

Ted Tsoがバグレポートの中 [launchpad.net]で書いていることを引用すると、

1.a) open and read file ~/.kde/foo/bar/baz
1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file
1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
1.d) close(fd)

Re: Ubuntu関係なくね？

[Anonymous Coward]

fsync()叩いても実際にDISKにカキコされる保証なんてないよ

Re: Ubuntu関係なくね？

[Huckle (37905)]

このDISKというのが、どのレベルのモノをさして言っているか/どの切り口から見ているのかにもよりますよね。:D

fsync()はOS内のライトバッファからOS外のデバイスに対する書き出し指示をおこなうものであって、デバイスへ書き込む(書き込み指示を出して完了応答を待ち合わせること)は保証されています。
(これがきちんとできていないのであれば、それは問題です)

ただし、デバイス内でのバッファードライトまで直接禁止するものではないので、仮にデバイス(たとえばHDD)内で揮発性のライトバックキャッシュが構成されていれば、突然の電源断でどうなるかはユーザにはわかりません。
(ドライバレベルでは、これをきちんと指示する仕組みはあります)

なので、エンタプライズ系のシステムでは、HDDのライトバックキャッシュ(WBC)をOFFにして使ったり、UPSをつけてWBC-ONでつかったり、ディスクアレイ装置側にNVRAMを搭載したりして、OS側に「書き込み完了」を返したときには、Stableであることを保証するようにしています。

元のACさんのコメントは、後者(デバイス内でStableなところにきちんと書かれることまで保証されるモノではない)、ということをおっしゃっているのだとおもいますが、ファイルシステムのレイヤの話(ここでのext4のコミットの話)と、デバイスの中の話は、どのレイヤの話を言っているのか、分けて説明しないと、周りの人が、びっくりしちゃいますよー。 :D