/**ファイルシステム総合スレ その8**/

1 名前：login:Penguin mailto:sage [2007/09/26(水) 15:39:21 ID:VZk+Fjj0] 過去スレ 　01 pc.2ch.net/test/read.cgi/linux/1006743807/ 　02 pc5.2ch.net/test/read.cgi/linux/1063025258/ 　03 pc8.2ch.net/test/read.cgi/linux/1101495293/ 　04 pc8.2ch.net/test/read.cgi/linux/1136695633/ 　05 pc8.2ch.net/test/read.cgi/linux/1152348695/ 　06 pc11.2ch.net/test/read.cgi/linux/1173530292/ 185 名前：login:Penguin mailto:sage >>184長文乙 [2008/01/12(土) 06:01:06 ID:jzLk1uOI] しかしこれだけストレージが大容量化されてくると、バックアップが大変。 HDDの障害はRAID構成で対処できるけど、 RAIDコントローラーの障害、ファイルシステムの破損は、 結局外部メディアにバックアップしておくしかない。 もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。 しかし常にLoadAverageが高いサーバだと、 バックアップのために割けるCPUリソースがない。 そこで、イベント処理型のバックアップシステムが必要とされてると思うんだけど。 とくにSANなどの外部共有ストレージが使えない低コストが求められる環境だとなおさら。 そういう需要って少ない？ 186 名前：login:Penguin mailto:sage [2008/01/12(土) 06:37:11 ID:bmbAU9+b] スレ違いだが…… >>184 それで嫌韓連中を増やしたことが韓国のメリットになったのか？ アップルもしくはその支持者の戦略だとするなら、まずそこを 検討しているはず、と思うのだが。 187 名前：login:Penguin mailto:sage [2008/01/12(土) 06:57:51 ID:SErII+Xc] >それで嫌韓連中を増やしたことが韓国のメリットになったのか？ 韓流ブームはTVと週刊誌で成立したものだと思ってるクチ？ その下地づくりが何時から始まったのか、調べてごらんよ 188 名前：login:Penguin mailto:sage [2008/01/12(土) 07:07:04 ID:bmbAU9+b] >>187 なにを示唆したいのか、さっぱり分からん。 てか、「ほのめかし」に終始して会話する気ないでしょ。 189 名前：login:Penguin mailto:sage [2008/01/12(土) 07:22:17 ID:SErII+Xc] 理解する気がないくせに「会話する気がない」って何様 190 名前：login:Penguin mailto:sage [2008/01/12(土) 10:50:20 ID:4BgmnGqv] >>185 真にバックアップの必要なデータって極わずか。 それらが大量にあるというなら、それなりの コストを払ってSAN上で２重化すれば。 つかCPUマシンとI/Oマシンくらい別にすれば。 191 名前：login:Penguin mailto:sage [2008/01/12(土) 11:09:04 ID:IDm5jJbB] >つかCPUマシンとI/Oマシンくらい別にすれば。 なんだその表現ｗｗｗ 192 名前：login:Penguin mailto:sage [2008/01/12(土) 11:27:17 ID:jzLk1uOI] >>190 SANが導入できる予算があれば苦労しないわけで。 しかしSANってかなりファイルアクセスコスト高いから、 大量の小さいファイル（HTMLとか）で 500GBとか占めてるサーバの差分バックアップ取ろうとしたら、 かなり時間掛かるんじゃないだろうか。 ブロックコピーだったら問題ないけど。 193 名前：192 mailto:sage [2008/01/12(土) 11:29:24 ID:jzLk1uOI] SANはSANでも共有ファイルシステムを使った場合の話しね。 194 名前：login:Penguin mailto:sage [2008/01/12(土) 11:52:55 ID:4BgmnGqv] >>192 >大量の小さいファイル（HTMLとか）で >500GBとか占めてるサーバの差分バックアップ取ろうとしたら それらが本当にバックアップ対象なの？ 差分とる必要があるなら、差分がとりやすいような構成に するんじゃないのか。何も考えずに/varに500GBとか やってるんすかね。 195 名前：login:Penguin mailto:sage [2008/01/12(土) 11:55:47 ID:yT37g0aU] >>185 そんなだらだらとしたバックアップが実際に役に立つと思いますか？ データの一貫性を保つためには、きちんと決められた時点のデータがすべて揃わないと何の意味も無いんですよ。 あなたみたいな、ハードウェア的な要件だけでしか物事を考えられないSEは邪魔なだけですよ。 196 名前：login:Penguin mailto:sage [2008/01/12(土) 12:26:21 ID:jzLk1uOI] >>194 HTMLの場合もあれば、2chのdatファイルのようなこともあれば、 Maildirのメールファイルのこともある。 HTMLやMaildirの場合はディレクトリ構成とかをこっちの自由にはしにくいから、 全体で差分バックアップを取る必要がある。 >>195 DBのバックアップじゃないから、OK。 HTMLの場合なんかだと、スナップショットを取る必要すらない。 決めつけの頭固いSE乙。 197 名前：login:Penguin mailto:sage [2008/01/12(土) 12:30:53 ID:iYG31qhb] Appleのドキュメント見に行ったけど、バックアップに使うというのは、 イベントによってファイルシステムのある瞬間の状態をとれるということだよね。 スナップショットをとってのバックアップだったらLVMとかでLinuxで既にやっているし？ あまりLinuxで似たような実装するとか(効果や労力の点で)考える必要ないんじゃない？ と思ったけど、そういうこととは違うの？ 198 名前：login:Penguin mailto:sage [2008/01/12(土) 12:43:43 ID:jzLk1uOI] >>197 いや、違う。 例えば100KBのファイルが5000000個あるボリュームがあって、 それの差分バックアップを取りたい場合、前回との差を調べるだけで、 １〜５時間ぐらい（バックアップ先やLAによって異なる）かかる。 でも実際にはほとんど更新されてなかったりして、 ファイルコピー自体は10分ぐらいで終わってしまったりする。 そこでどのファイルが更新されたのかをイベント処理によって検知して、 その更新されたファイルリストを作っておき、 そのファイルだけをコピーするようにすれば、 差分バックアップがあっという間に出来てしまう。 これなら１時間おきに差分バックアップを取ることも可能。 ってことをやりたい。 199 名前：login:Penguin mailto:sage [2008/01/12(土) 13:07:29 ID:iYG31qhb] ionotify APIを使えばできるようになるのかなあ www.linux.or.jp/JM/html/LDP_man-pages/man7/inotify.7.html うーん、これを利用するプログラムなら、もうあった気がする。 というかそのプログラムの説明でこのAPIを知った筈なんだが。 200 名前：login:Penguin mailto:sage [2008/01/12(土) 17:24:53 ID:Y+I93RRs] lsyncd www.pri.univie.ac.at/index.php?c=show&CEWebS_what=Lsyncd これか？ 201 名前：login:Penguin mailto:sage [2008/01/12(土) 17:37:47 ID:zybZJIGE] で、ループしてinotifyは監視できるノード数に限界があって・・・、で戻る。 inotifyで/以下監視しようとするとさくっと死亡します。 ただし、/home以下ならユーザー数や利用のされ方しだいでは可能。 現実的な策としてAppleの実装は参考になるよ。 もっとも根底からinotifyとは違う方式なので、単にログサーバが 別途あればいけるというようなことにはならない＞Linux 202 名前：login:Penguin mailto:sage [2008/01/12(土) 17:56:05 ID:Bx7hU4VM] >>198 > HDDの障害はRAID構成で対処できるけど、 > RAIDコントローラーの障害、ファイルシステムの破損は、 > 結局外部メディアにバックアップしておくしかない。 > もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。 よくわからんが、その「どのファイルいぢったかイベントドリブンでメモしときましょう型」 バックアップってさ、結局そのメモスレッドが走ってるCPUマシンが障害起こしたら おしまいじゃねーの? バージョン(世代)管理型のバックアップでもないようだし RAIDコントローラーの障害を心配して、RAIDにしない理由がいまいちわからん。 RAIDコントローラーを一枚(or一台)余計に 買って使わないで保存しとけば、RAIDでOKじゃね? 203 名前：login:Penguin mailto:sage [2008/01/12(土) 20:48:27 ID:1iC8xxCD] >>202 ID:jzLk1uOI はRAIDを使わないとは言ってないのでは？ RAIDがあってもバックアップは大切。 そのバックアップを早くしたいって話なんじゃないの？ 204 名前：login:Penguin mailto:sage [2008/01/12(土) 22:13:37 ID:jzLk1uOI] >>201 同意。 >>202 203の通り。 >>203 代わりのレスあり。 205 名前：login:Penguin mailto:sage [2008/01/12(土) 22:16:35 ID:4BgmnGqv] >>204 金も知恵も使いたくないなら RAID１やってバックアップとるとき抜いて、 別マシンで差分とればいいんじゃね？ 206 名前：login:Penguin mailto:sage [2008/01/12(土) 22:23:07 ID:jzLk1uOI] >>205 RAID1の片方のHDD抜いたら、 ホットスペアディスクに転送始まって、 終わるまで重くてしょうがないよ。 それにわざわざデータセンター行かないとできないし。 207 名前：login:Penguin mailto:sage [2008/01/12(土) 23:01:22 ID:Bx7hU4VM] >>204 RAID5/6でもダメ? バックアップ取りたいってのは分かる気がするけど んーとさ、これってファイルシステムレベルで やる話なのかな?って思った。 アプリケーションレベルで保存先二つにするとか、 ユーザのログアウト時にユーザの書き込み範囲だけ バックアップ同期するとかそんなんでもよさげな気がす。 208 名前：login:Penguin mailto:sage [2008/01/12(土) 23:28:26 ID:gMk/W/4K] >>207 というかブロックレベルでやればいいよな、と思った。なに？EMC高い？AX4なら100万以下だぜ 209 名前：login:Penguin mailto:sage [2008/01/12(土) 23:43:07 ID:Bx7hU4VM] >>208　そりゃそれなら文句ないだろうけど。 ここの話で、確かにもう少しそういうものの小規模、低コストなものは需要があるのかもしれんね、とおもた。 210 名前：login:Penguin mailto:sage [2008/01/12(土) 23:58:53 ID:D/8nBsgE] クラスターファイルシステムもここでいいんかな？ iSCSI+ocfs2でファイル共有したいんだが、centos5.1とubuntu7.10だと同時にマウントできない centos5.1同士、ubuntu7.10同士は問題ない centos5.1がocfs2 1.2.7-1、ubuntu7.10がocfs2 1.24 バージョン違うと共有できんのかな？ gfs2はバージョン違うとダメだったりします？ ocfs2とgfs2のそれぞれの利点がさっぱり分かりません・・・ 211 名前：login:Penguin mailto:sage [2008/01/13(日) 10:03:01 ID:Nollm+Al] >>210 基本的に、クラスタで両方からいっぺんにアクセスされる可能性があるものの場合は バージョンをあわせなきゃダメだろ。バージョンが違うと言うことは機能に違いが あるということなのだから。 212 名前：login:Penguin mailto:sage [2008/01/13(日) 13:45:13 ID:uE2Jrzt9] >>204 nzfug.nz.freebsd.org/nzfug/AndrewThompson/ZfsForReplication FreeBSDの話だけど。 ZFSでsnapshot作って、前回のsnapshotとのバイナリ差分をリモートに送信・同期させる方法。 213 名前：login:Penguin mailto:sage [2008/01/13(日) 14:04:33 ID:weLbJnIm] そういえばUNIXマガジン買ったやつはいないのか。 214 名前：login:Penguin mailto:sage [2008/01/13(日) 14:42:06 ID:T1kxn9Tz] >>208 そのAXなんちゃらEMかんちゃらも高いからなあ。 なら自分は手順覚えれば無料のを使った方がいいや。 215 名前：204 mailto:sage [2008/01/13(日) 22:38:13 ID:PiB7mojI] >>207 > アプリケーションレベルで保存先二つにするとか、 Webアプリが出力したデータをバックアップするときは、この方法使うこと多いね。 けど、FTPでアップされたファイルとかだと デーモンをいじらないと出来ないから、キツいねー。 >>212 おっ、これ理想的かも。 216 名前：login:Penguin mailto:sage [2008/01/14(月) 00:20:29 ID:qmocvwzd] NetBSD上でだけど、ファイルの書き込みや移動、削除が発生すると ファイルパスを通知するファイルシステムを昔作ったよ。 理由はmknmzが毎度毎度ディレクトリを全部スキャンして遅かった からなんだけど…。 既存のファイルシステム(overlay filesystem)のコードを流用したから、 結構簡単に作れたよ。 Linuxでも検討してみたけど、ファイルシステムの設計がスタッカブル じゃないんで面倒臭くなってやめちゃったなあ。 今ならFUSEとunionfsを駆使すれば、同じようなことでできるんじゃないかな？ 217 名前：login:Penguin mailto:sage [2008/01/14(月) 00:37:09 ID:6n5zEajJ] aufs使えばできそうだな。 218 名前：login:Penguin mailto:sage [2008/01/14(月) 02:19:06 ID:qPxdU3yy] vfsで実装 219 名前：210 mailto:sage [2008/01/15(火) 02:26:55 ID:BF3bHG9k] >>211 やっぱそうですよね、合わせないとダメですよね・・・ ubuntuの方を1.27にしてみます ocfs2とgfs2の違いは相変わらずよく分からん、ocfs2の方が設定簡単そうぐらいしか 220 名前：login:Penguin mailto:sage [2008/01/15(火) 03:29:14 ID:Ar++HS05] SDカードのFATエントリなんか他のエリアと比べて 何倍も書き換えられると思うんだけど フラッシュメモリの使い方として問題ないの？ 221 名前：login:Penguin mailto:sage [2008/01/15(火) 03:30:48 ID:jvp0V+W6] 今はフラッシュメモリ側で散らす機能があるでしょ。 222 名前：login:Penguin mailto:sage [2008/01/15(火) 03:40:12 ID:Ar++HS05] ほー、なるほど賢いね。 カードに直接そういう機構がそなわってるってこと？ それともカードを扱う使用機器のドライバ側ってこと？ 223 名前：login:Penguin mailto:sage [2008/01/15(火) 03:42:21 ID:edpzbljx] カード側で持ってるよ。アルゴリズムは各社の極秘中の極秘だそうだ まあカードの書き換え速度や寿命に如実に影響する肝の部分だしな 224 名前：login:Penguin mailto:sage [2008/01/15(火) 03:54:19 ID:Ar++HS05] なるほどありがとう。 しかしそうするとメモリーカード上のフラグメンテーションって 純粋に仮想的なもので実測には影響しないのかな。 225 名前：login:Penguin mailto:sage [2008/01/15(火) 03:57:55 ID:edpzbljx] フラッシュメモリはSDRAMみたいにバーストリードで速度が上がるとかいう要素は無いだろう ランダムリードと言っても元々数KB〜数十KB単位のセル単位で読み書きだし そのセルが物理的に離れた箇所にあったとしても、スピンドル回してヘッドがギコギコ動く訳じゃないから どれだけアクセス時間がかかるかとかはほとんど誤差の領域じゃないかねえ まあ俺も素人だから正味のところはわからんが それよりもコントロールロジックの処理速度の方が遥かに影響が大きそうだ 226 名前：login:Penguin mailto:sage [2008/01/15(火) 04:23:10 ID:RzvkwwJj] 知ってる方がいたら教えてほしいのですが、ext3のdata=journalのモードってのは 本当にフルデータジャーナリングなのでしょうか。メタデータだけじゃなくて、データ の変更についてもジャーナルログに書き出してるんでしょうか。 大抵の文書には、 「フルデータジャーナリングじゃ」だから「2度データが書き出される」と書いてあるのですが、 @ITの記事によると「journalモードではディスクへの書き込みが完了したことを確認してから ジャーナリングの記録を行う」とありまして、同期書き込み＋メタデータジャーナリングのよう な解説をしてあります。これだとデータの書き出しは1度だけです。 www.atmarkit.co.jp/flinux/rensai/fs04/fs04b.html 詳しく解説してあるので、@ITの方が正しいような感じがするのですが、どんなもんでしょう。 それからもう一つ疑問なのですが、フルデータジャーナリング使うぐらいなら 同期マウントした方が良い気がするのですが間違ってますか？ （同期マウントでもメタデータの更新中に停電したらアウト…なのかな） アホな質問ですいません 227 名前：login:Penguin mailto:sage [2008/01/23(水) 01:52:59 ID:N7D3q8Og] ここで言う同期マウントって例えば？ 228 名前：login:Penguin mailto:sage [2008/01/23(水) 13:49:47 ID:1HOl8oN3] -o sync, dirsync 229 名前：login:Penguin mailto:sage [2008/01/23(水) 14:27:45 ID:l6jXIqfH] 同期モードでmountしている状態でもクラッシュしたらfsckが必要ですし 実現できる機能が違いますよね 230 名前：login:Penguin mailto:sage [2008/01/25(金) 05:13:31 ID:V+xKWgCR] そもそも同期モードで書いてる途中で落ちたとして、 どこまで何を書いたかは誰が覚えてるんだろうねぇ？ 231 名前：login:Penguin mailto:sage [2008/01/25(金) 19:51:15 ID:OAhQQFKa] 誰も覚えていない。 書き込みそのものがなかったものになるだけ。 232 名前：login:Penguin mailto:sage [2008/01/26(土) 07:10:51 ID:nkamkNao] それはジャーナル有る場合だろ 233 名前：login:Penguin mailto:sage [2008/01/26(土) 07:50:09 ID:8OpwyOTH] はあ？ 234 名前：login:Penguin mailto:sage [2008/01/26(土) 14:24:53 ID:nFnPAV3G] 同期・非同期とトランザクションの区別はつけようぜ。 235 名前：login:Penguin mailto:sage [2008/01/26(土) 15:24:51 ID:Pvih2f3X] >>232 fsckでなかったものにされるんじゃね？ ジャーナルなんて関係ないでしょ。 236 名前：login:Penguin mailto:sage [2008/01/26(土) 15:53:50 ID:8QyNar63] >>235 fsckすると残りのジャーナルを適用することもある。 どっちが整合性を保ちつつデータを保全できるかによるようだ。 237 名前：login:Penguin mailto:sage [2008/01/26(土) 17:14:55 ID:X0RlC9mR] ちょっとまて >>226の >フルデータジャーナリング使うぐらいなら同期マウントした方が良い かどうかだろ ジャーナリング無しで同期書き込みしたらfsckでロールバックかかるってこと？？ 238 名前：login:Penguin mailto:sage [2008/01/26(土) 17:25:57 ID:IqVOKU/f] ちゃんと流れ読めよ 239 名前：login:Penguin mailto:sage [2008/01/26(土) 19:00:37 ID:Pvih2f3X] >>236 なんでそうなるのか、それがわからん。 同期の場合は、sync（）にしろwrite（）にしろ、書き込みがすべて終わるまで戻ってこないんでしょ？ 対象がジャーナルFSであっても。 >>237 fsckで行う作業をロールバックというな。 240 名前：login:Penguin mailto:sage [2008/01/26(土) 21:51:13 ID:X0RlC9mR] 状況がよく分からんのだが、ファイルの内容書き換え中に落ちたとして、 fsckでどうやってロールバックされるわけ？ >>230な状況になるんじゃないのか 241 名前：login:Penguin mailto:sage [2008/01/27(日) 01:29:39 ID:LrB7nbuV] RDBMSの場合は、SQLレベルでの論理的な操作すべてが記録されているから、 直前のバックアップデータに対してログをリプレイすることで、完全復旧ができるというわけだが、 ファイルシステムに当てはめて考えれば、バイトレベルの操作すべてに対してログが採られていなければ、データの中身までは保障できないということになる。 現実的には、そんなことしてたらログの量がとてつもなくなるから、到底無理な話。 ジャーナルFSが復旧処理でやっていることは、通常のfsckがすべてのファイルに対して実行する検査を ログをなめることで省略しているにすぎない。 当然、正常に閉じていないファイルは、問答無用でlost+found逝きとなる。 これをロールバック/フォワードなどという言うには違和感あるでしょ？ 242 名前：login:Penguin mailto:sage [2008/01/27(日) 03:02:00 ID:i1WeOFxf] >>241 データについてもする場合はopen以後のwriteは別領域に書いて、 適当なタイミングでFS構造からの参照を付け替えればいいだけ。 この場合、write中にクラッシュした後の復旧でロールバックする。 ただし XFS とかの実装だとcreat自体はコミット済みだから ０バイトファイルが残ってくれたりとある意味困った挙動になったり。 さらに進んでNTFSとかreiser4ではアプリ側からトランザクション性を 制御した書き込みができる（た？）はずだけど、どういう形なんだっけ？ あとfsckがやってるのは正常に閉じられなかったファイルではなく、 参照があるのに参照先がないとか、参照がないのに実体があるとかの FS構造としての不整合状態をブロックをなめて発見したものを lost+foundに集めたりクリアしたりしてるだけで、閉じられなかった ファイルを救ってるわけではない。 243 名前：login:Penguin mailto:sage [2008/02/02(土) 17:24:24 ID:Sk+gOLYe] どこのスレが該当するかわからんがとりあえずここに。 mdadmでraid1構築、ocfs2にフォーマットしてマウントは問題ないんだが、 raid0とraid10で同じ事をやると失敗する。 (ひとまずローカルディスクで実験してます。最終的にはiSCSIを複数使ってやる予定) 以下マウント時のエラー ocfs2_hb_ctl: I/O error on channel while starting heartbeart mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: "Operation not permitted" /etc/init.d/o2cb statusすると確かにハートビートが動いてない。 んで手動でocfs2_hb_ctl -S -d /dev/md7(作ったRAIDデバイスがmd7)実行するも ocfs2_hb_ctl: I/O error on channel while starting heartbeart でダメ。 これはocfs2の仕様なんですかね？GFS2だとなんとかなる？ clvmで-iと-mのが可能性あったりするのかなあ、もうわけわからん 244 名前：login:Penguin [2008/02/06(水) 21:12:32 ID:xB+Vp2Cl] トーバルズ：OS XはVistaよりマシ、でもファイルシステムはゴミ japanese.engadget.com/2008/02/05/linus-os-x-vista/ ktkr 245 名前：login:Penguin mailto:sage [2008/02/06(水) 21:24:53 ID:xsQFoZY7] 誰か言ってやってくれ LinuxはServer2008よりマシ、でもファイルシステムはゴミ 246 名前：login:Penguin mailto:sage [2008/02/06(水) 21:35:04 ID:CEBTMN4n] >>245 いやそれは逆だろ。 ファイルシステムはマシだが・・・。 247 名前：login:Penguin mailto:sage [2008/02/06(水) 21:43:01 ID:bycraF9D] NTFSってどうなん？ 248 名前：login:Penguin mailto:sage [2008/02/06(水) 21:45:17 ID:AbBwRF41] ゴミ 249 名前：login:Penguin mailto:sage [2008/02/06(水) 21:45:58 ID:kmV4D3eE] 速度的に光るものはないが、耐久力はゾンビ級。 ext3なんかよりよっぽど優れたfsだと思うんだけどな… 250 名前：login:Penguin mailto:sage [2008/02/06(水) 21:59:15 ID:MW2Uiq4L] >>249 それ賛同 251 名前：login:Penguin mailto:sage [2008/02/07(木) 00:55:39 ID:Jh0j2rM7] リーナスってバカだな 252 名前：login:Penguin mailto:sage [2008/02/07(木) 03:33:18 ID:UdsqPHwZ] ntfsでファイルがぶっ飛んで破片も出てこないのはプログラムが悪いの？ 253 名前：login:Penguin mailto:sage [2008/02/07(木) 10:56:01 ID:NVBqFf6j] 俺なんかはntfsよりreiser・・・じゃなかった、xfsで何事も無かったように再起動できたことに驚愕したものだが。 ntfsだとどっか壊れるよなーという落とし方をしてしまった時のことだ。 まぁxfsはfsckしないからというのもあるだろうが。 254 名前：login:Penguin mailto:sage [2008/02/07(木) 11:16:04 ID:JbuBRM/5] >>253 どこかに0バイトのファイルが転がってるかもよ。 255 名前：login:Penguin mailto:sage [2008/02/07(木) 17:47:13 ID:nagQT8db] ちなみにどういう落とし方したの？ 256 名前：login:Penguin mailto:sage [2008/02/07(木) 18:16:17 ID:lsDyIYji] 酒を飲みつつ恋愛論を語った 257 名前：login:Penguin mailto:sage [2008/02/07(木) 18:26:42 ID:MhI2GJBO] たしかにntfsだとぶっ壊れそうだ。 あとできちんとf*ckしとけよ。 258 名前：login:Penguin mailto:sage [2008/02/08(金) 02:06:16 ID:5Qp7toYJ] いったいなんのスレだよw >>253 xfsはマウント時にfsckするんじゃなかったっけ？ 259 名前：login:Penguin mailto:sage [2008/02/08(金) 02:20:17 ID:SRnPVqDy] >>258 昔のxfs_fsck.c int main(int argc, char **argv) { return 0; } 今はshell scriptになったな。 260 名前：不明なデバイスさん [2008/02/08(金) 07:58:24 ID:YoHKP6tC] >>198 索引の更新日付は収容ファイルの更新で変更になる、 だから索引の更新日付をチェックして前回バックアップした日付以前なら その索引直下に収容のファイルは対象外にできる、 そうすれば処理時間は一桁以下にできるのでは。 261 名前： ◆YtPQzYyEH. [2008/02/08(金) 15:40:09 ID:C4+Xg+NF] 262 名前： ◆JuFLxjEbXg [2008/02/08(金) 15:42:03 ID:C4+Xg+NF] な 263 名前：login:Penguin mailto:sage [2008/02/08(金) 16:39:10 ID:lO2z0Hih] NTFS自体は機能とパフォーマンスを考えたら PC用のファイルシステムではトップクラスじゃねーかと思う 大元のHPFSが優れていたんだろうな しかしNTやVistaでさえその機能をきちんと使っていない点でクソ それとフラグメント化が激しすぎるのもクソ HFSは褒める部分を探すのに苦労して苦労して、それでも何も見つからないくらいにクソ さらにそれを告げると信者が火病起こしてわめきだすのがさらにウザくてクソ ext系は、とりあえず動きますよって段階では不満は無いんだが それ以上のものでもないし、お世辞にも優れた部分は見出せない 偉大なる平凡 xfsは、こんなもんタダで使わせてもらって本当にいいんスか？って感じだな jfsは知らん reiser fsはこれからどうなっちゃうの？って感じ 264 名前：login:Penguin mailto:sage [2008/02/08(金) 16:49:38 ID:B7rrj2AA] NTFSは異常終了無しで半年使って、chkdskかけたら数千ファイルのaclが吹っ飛んだことがorz FSが問題なのかどうか微妙なラインだが手痛かった。 xfsはcronでデフラグかけてるといい感じでうごいてる。 reiserは・・・ボリュームでかいとマウント時にものっそ時間かかるんだが・・・ 265 名前：login:Penguin mailto:sage [2008/02/08(金) 18:25:44 ID:WpMOTmXO] xfsは古いマシンで使うぶんには良いんだけどね。 新しいserverに入れる気はおきないな、mlみてたら怖くて。 266 名前：login:Penguin mailto:sage [2008/02/08(金) 18:42:58 ID:PGSC+VCd] >>264 それはどんなファイルシステムでも書き込んだ後1度も読み取りもしなかった領域が 不良セクタ化したらウンコーッ　って話だろ。 267 名前：login:Penguin mailto:sage [2008/02/08(金) 18:47:17 ID:oKxB/QKg] >>265 新しいマシンだと何か不具合出るの？ 最近のコードが安定してない、って話なら分かるけど。 268 名前：login:Penguin mailto:sage [2008/02/08(金) 22:53:36 ID:5Qp7toYJ] xfsはシュルシュル、reiserfsはヌルヌル。 性能いいのはreiserなんだろうけど、 xfsはそこそこ性能を発揮して低負荷。 >>259 あーあー、そうだったそうだった。 月イチxfs_check使ってるので忘れてたわ。 269 名前：login:Penguin mailto:sage [2008/02/09(土) 11:55:22 ID:I5g2yu0o] >>264 MSKB831374、831375、327009、873437とか該当してなかった？ 270 名前：login:Penguin mailto:sage [2008/02/09(土) 12:20:37 ID:woPPxICV] xfsはファイルの削除が遅い。カーネルツリー削除するのに時間がかかるよー。 271 名前：login:Penguin mailto:sage [2008/02/09(土) 13:11:25 ID:aL9fnslD] 削除なんてバックグラウンドでやらせときゃいいじゃん 272 名前：login:Penguin mailto:sage [2008/02/09(土) 13:18:17 ID:JxDwlQM6] >>266 いやRAIDだし不良セクタ関係ないw ハード障害に対するFSの耐久性の話ではない。 273 名前：login:Penguin mailto:sage [2008/02/10(日) 21:20:25 ID:zTNy08k4] 3wareのRAID板で1TB*3のRAID5を構築したのですが、 Linuxのファイルシステムとしてデータ領域に適しているのはどれになるんでしょうか？ CPUはGeodeNXのDualなのでパワーはあまりありません。メモリは2GB積んでます。 reiserfsとXFSとで検討の枠を絞ってしまっていいものか、 最近のトレンドが分からないのでご意見ください。 現状持ってる数年前のイメージでは以下の感じ。 XFS ○　ファイルシステムが大きくてもマウントが早い ○　あまり負荷がかからない ○　reiserfsより早い ×　ファイルの削除が遅い ×　fsckちゃんとしてるのかよく分からない・・・ reiserfs ○　ファイルシステムの縮小が唯一できる ×　ファイルシステムが大きくなるとマウントが遅い 最近はどうなんでしょうか？ 274 名前：login:Penguin mailto:sage [2008/02/10(日) 21:29:22 ID:GwVP/ZS2] >>273 個人で使うなら大して変わらないから好きなの使えば? 275 名前：login:Penguin mailto:sage [2008/02/10(日) 21:33:29 ID:BEDS9Otr] 個人で1TBx3か？すごいな 276 名前：login:Penguin mailto:sage [2008/02/10(日) 21:43:31 ID:GwVP/ZS2] >>275 1TB 2.5万だからちょっとしたおもちゃだろ？ 277 名前：login:Penguin mailto:sage [2008/02/10(日) 22:46:57 ID:41EqjFSS] 1Tx3が2.5万x3 ML115が1.5万 メモリ2Gを0.5万で追加したとしても 9.5万で2TなNASが用意できる時代ですぜ。 278 名前：login:Penguin mailto:sage [2008/02/10(日) 22:52:26 ID:kPqZgS0L] 知らない間にバカ安になってるな。 うちのノートPCのHDDも取りかえたい。 279 名前：login:Penguin mailto:sage [2008/02/10(日) 23:13:04 ID:jaGVAHE6] 1Tも入れるものが無い 280 名前：login:Penguin mailto:sage [2008/02/11(月) 00:55:40 ID:v/vK9WxC] >>273 どちらが良いとは言わない、だがこれだけは言わせてくれ。 ・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 ・プロセス毎で使えるメモリ量は限られている。(特に32bitな環境では) ・メモリを増設しても、プロセス毎で使えるメモリ量は変わらない。 281 名前：login:Penguin mailto:sage [2008/02/11(月) 00:57:39 ID:NXuZoz9l] >>280 >・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 すごくフラグメントしてたり、むちゃくちゃになってしまった時に 必要なだけで、普段はそんなに要らない。 もっともcheckやrepairが必要なときは、かなり終わってるけどな。 282 名前：login:Penguin mailto:sage [2008/02/11(月) 12:55:43 ID:hHXFn50e] >>281 > > xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。 > すごくフラグメントしてたり、むちゃくちゃになってしまった時に > 必要なだけで、普段はそんなに要らない。 俺は、良く聞く4MB/i-nodeにつき128MB/RAMという、xfs_repairの昔からの定説から 1TBならi-nodeはおよそこれ位だから、RAMはだいたい1GB的な一般解を>>280は導いてきたと思ったんだが i-nodeの大きさだけじゃなく、フラグメントも関係あるのか？ 俺はツーリングとか、息子の運動会、家族旅行で流し撮りした映像の置き場や、編集用として WD7500AAKS×4を2410SAでRAID5運用していたわけだが、RAMは1GBしか積んでない 当然中身はGBオーバーの動画ファイル群のみ だが突然の電源断や、停電などで落ちた際にxfs_checkをかける時でも、これまで一度として メモリが足りなくなったりしたことはこれまでなかった 俺はこれをエクステントが効いている為に、i-nodeの大きさ自体はそれほど増えていないからだと 理解していた訳なんだが、もしフラグメントが関係しているなら、一度もxfs_fsrをかけたこともなく 使用量も80%を余裕で超えているこのディスクは、相当に断片化しているはずなんだけどな 283 名前：login:Penguin mailto:sage [2008/02/11(月) 13:01:33 ID:L4qR2Tu7] フラグメントは関係ない 284 名前：268 mailto:sage [2008/02/12(火) 02:16:28 ID:XWn0I4iF] >>280 システム移行時にサブ(メモリ256MBのP3)機で1.5TBのxfs_checkしたけど、 メモリ食う仕様忘れててswapディスクなしだと見事に固まったな。 低速ながらswapディスク付けたら一晩ちょいでどうにか終わってた。 285 名前：login:Penguin mailto:sage [2008/02/14(木) 10:51:10 ID:U8W3css3] ttp://www.smalltown.ne.jp/~usata/diary/?date=20080213#p01 おれもxfsってたまに重くなると思ってた。 こういうのもログを別ディスクにしたら性能あがるのかね

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef