The -W1 switch enables the write cache of a hard disk and will cause severe file system corruption in face of a power outage that occurs while a write operation is in progress. Journalling file systems (reiserfs, ext3fs, xfs, jfs, you name it) cannot help about this either, but may instead hide the actual problem. These file systems rely on their write operations being performed in order.
2.6.20 Changelog (スコア:5, 参考になる)
屍体メモ [windy.cx]
Re:2.6.20 Changelog (スコア:4, 興味深い)
2.6.20-rc6(7?)あたりから起きている、vt8237をsata_viaで使うと、SATAドライブ(日立製)が突然ロックアップして止まる現象の原因らしき事が-rc7以降のパッチで改善していると書いてあるのですが、どんなものだか(;´Д`)
2.6.20-rc7時点の安定性を考えると、又、例によってUnstableなのかもしれないな(;´Д`)と思ってこわごわと様子を見ています(^^;
ieee1394(Re:2.6.20 Changelog) (スコア:1)
lkmlでバグレポートとパッチが錯綜している状況で全て追いかけるのが容易では無いですが、このスレッドあたり [iu.edu]が根本的な解決策のひとつかもしれません(って、これから色々パッチを試していく訳なので可能性の提示だけに留めておきますが)
それにしても、2.6.20-rc1段階でコードを大掃除しただけならばいいんですが、それが設計にまで踏み込んだ「掃除」であったがためにバグを埋め込む原因になったり、それ以前に次世代の新しく根本から設計しなおした1394スタック(これは、http://www.linux1394.org/ [linux1394.org]で公表されていましたが、今は開発凍結中の模様)が既にSVNにCommitまでされているのにそういうリスキーな「大掃除」をやるか?とか、今回の件に関しては、メンテナ氏の考えと言うか思考回路を疑ってしまいます(;´Д`)
Re:ieee1394(Re:2.6.20 Changelog) (スコア:0)
Re:2.6.20 Changelog (スコア:3, 参考になる)
だからこそ概要程度のものが欲しいというわけです。@ITの記事の方とかがすごいと思います。
2.6.19シリーズのmmap壊れ問題かどうかはわかりませんが、2.6.19が出た直後に差し替えたら多くのサービスがなぜかコケるという事態に遭遇し、2.6.18.3に戻したことがありました。
今回は特にそういう問題もなさそうなので少し安心してます。
-- やさいはけんこうにいちば〜ん!
Re:2.6.20 Changelog (スコア:4, 参考になる)
すると、スクリプトでダイジェストっぽいとこだけ拾えそうな感じがしたのでやってみました。
http://fuga.jp/~densuke/diary/?date=20070205#p05 [fuga.jp]
フォーマットに変化がなければ、今後も抽出できるかも。
-- やさいはけんこうにいちば〜ん!
Re:2.6.20 Changelog (スコア:4, 参考になる)
Re:2.6.20 Changelog (スコア:1, 参考になる)
ここにもちょっとだけありました。タイトルが2.6.12になってますが、内容はそれっぽいです。
Re:2.6.20 Changelog (スコア:1, 参考になる)
これ、カーネル側に問題があったってことかねえ。
Re:2.6.20 Changelog (スコア:1, 興味深い)
3年前と2年前にファイルシステム(ext3)のバグによるデータ破壊に泣いているので、
Linuxのファイルシステムは信用しないようにしてます。
ext3 は枯れていると信じたい (スコア:2, 興味深い)
あくまで願望でしかないんだよなぁ。
実際、mmap 周りが犯人とはいえ今回もデータ飛んでるし。
自分は今のところ致命的な自体は経験したことが無いけど単に幸運なだけか。
その「経験したバグ」ってACL周りとかじゃなくて、
ファイル本体あるいはファイルシステム全体が吹っ飛ぶような状態?
今の仕事では業務データの多くが AIX5L JFS に入ってるんですが、
さすがにこういう商用のものは大丈夫なんだろうな。
屍体メモ [windy.cx]
Re:ext3 は枯れていると信じたい (スコア:2, 興味深い)
ジャーナルまたは、キャッシュの書き戻しに問題があったらしく、
ファイルを編集してしばらくは大丈夫だけど、数時間後、ディスクに書き出されるときにファイルが破壊されていきました。
問題のあるファイルを特定し、バックアップから修復、動作確認をして、一息ついたころに、ファイルがぶっ壊れる恐怖。
ファイルシステムのバグの前には RAID も無意味なんで、もっと安定させて欲しいものですね
Re:ext3 は枯れていると信じたい (スコア:1, 興味深い)
>さすがにこういう商用のものは大丈夫なんだろうな。
私の経験でも、Linuxではファイルシステムを壊した経験があるけど、
AIXのJFSでは無いなあ。
(HDDの故障はしょうがないとしても)
4L時代のJFSは頻繁にdefragfs をやる必要があったのは鬱陶しかったけど。
でも今の職場はext3がごろごろ。たーくさん。
Re:ext3 は枯れていると信じたい (スコア:1, 興味深い)
#かなり作り直したからAIX向けJFSのソースツリーとは別らしい。
結局商用かどうかじゃなくて、枯れるまで時間と人的リソースをつぎ込めたかどうかじゃないのかな。
#OS/2向けはそれができずに最後までHPFS386からの乗り換えを促すことが出来なかったと思う。
Re:ext3 は枯れていると信じたい (スコア:1)
集中してパッチを出してくれますから。
まあ、そういうところに商用としてお金を払っているんですけどね。
やっぱり業務で使う分には物理的に他メディアへバックアップを取る
のは管理する側からすれば当然なので、たとえデータが飛んでも、
OSメーカに文句は言っても、泣き言は言わない。
私のところはHP-UXが多いのですが、ファイルシステム関連のパッチ
はHPからバラバラとよく出てますね。相当クリティカルだというもの
しか適用しませんけど。
そもそも正しく書き込めないのが困る (スコア:1)
改竄対策で Tripwire のようなもの(ハッシュとかその他もろもろの付加情報も取る)を作ってファイルのデータベースを作成し、定期的に健全性をチェックするということは(要件に入っていたので)やっているものの、リアルタイムではないしそもそも最初から正しく書き込めてなかったりしたらどうしようとか orz
考えすぎると眠れない。(考えなければ眠れる)
屍体メモ [windy.cx]
Re:ext3 は枯れていると信じたい (スコア:0)
HFS+ (スコア:1, 興味深い)
FAT32のWindowsはあまり壊れた記憶がないですね。
もう少しHFS+もどうにかしてほしい。
Re:HFS+ (スコア:0)
そして、安定性を求めてufsにするとさらに大はまり。なんせOS XのufsはOS XServerではbootパーティションではufsがつかえないようにしたという曰く付きのシロモノ。
ってことで、現状まともなfsが使えないOS Xですが、ZFSが早い事OS Xに移植されないものかなぁ…
Re:HFS+ (スコア:0)
ま、Windowsでも壊れたことないしな。FATでもNTFSでも。
Linux? 壊れたよ、玄箱で。
Re:2.6.20 Changelog (スコア:0)
あと、そのバグのBTSの番号を教えてください。
#Linux = ext3なのか?
Re:2.6.20 Changelog (スコア:1)
SGI出身の結構実績のある(はず)ファイルシステムなのですが、CentOS ではデフォルトで対応してなかったり。
ファイルシステムも何種類か調べてみたんですが、付加価値(や実績)を求めると、フリーのものには「これだ!」というものが無い気がします。
ん? 俺、今何か言った?
Re:2.6.20 Changelog (スコア:0)
Re:2.6.20 Changelog (スコア:0)
FAT32。
歴史もあるし信用できる。とても枯れてる。
さまざまな環境で動き、ポータビリティが高い。
>あと、そのバグのBTSの番号を教えてください。
BTS?
ナニソレ?
Re:2.6.20 Changelog (スコア:0)
なぜなら、inode制限がなし、断片化しにくい [oracle.co.jp]からです。
ただ、RHELだとインストーラでサポートされていない [dtpwiki.jp]、ブートにつかえないらしい [tdiary.net]。
Re:2.6.20 Changelog (スコア:0)
http://freshmeat.net/projects/hdparm/
壊す前に切っておこう、Write cache。
Re:2.6.20 Changelog (スコア:0)
必要なソースだけ選んでダウンロードする機構がほしい今日この頃。
暇な時があれば作ろう、、と思いつつ暇が無い。
いつ暇になるかわからないのでanonymous
Re:2.6.20 Changelog (スコア:1, 参考になる)
ソースの数十MBってのはもちろん、モジュール化したのに圧縮しても数MBって何やねん。
make zdiskでフロッピーに書き込んで起動チェックしていた頃が懐かしい…。
Re:2.6.20 Changelog (スコア:0)
Re:2.6.20 Changelog (スコア:1)
ペンギン
次はなんだろ
旅に出ます.(バグを)探さないで下さい.