[過去ﾛｸﾞ] ジャーナリングファイルシステム (756ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
47: [sage ] 2001/05/02(水)22:48 AAS
ごめん。ごめんよ・・・
そんな豚無くても・・・
48(5): 2001/05/04(金)01:58 AAS
>>46
jfs FS を mount したまま電源きって再起動してみ。
filesystem dirty と表示されて、mkfs するまで二度とその fs をマウントできなくなるから。
49(2): 2001/05/04(金)02:08 AAS
IBM JFS や SGI XFS とかだと書き込みだけでなくて
読み出しのスピードが上がっているの?
古典的な UNIX FS の系列だとディレクトリ内のファイル数が
増加すると ls のスピードも落ちるみたいなんだけど。
>>46
それって OS/2 とか AIX でもなるの?
JFS for Linux だけならまだいいんだけど。
50: 49 [sage ] 2001/05/04(金)02:13 AAS
>>46 は >>48 の間違い
鬱堕氏脳
51(1): CCルリたん。 2001/05/04(金)02:21 AAS
>>49の下
大丈夫だよ。以前AIXがあったけど、停電でも耐えたから。
52(1): Mary β 2001/05/04(金)03:55 AAS
>>51
まだきっとJFS for Linuxって、AIX上のJFSほどの信頼性はないと思う。
File Systemのコードって、VFSやVMの影響を結構受けるからね。
個人的にkernel-2.4.3でReiserFSを使ってるけど、一度kernel-2.4系
でmountしたvolumeを2.2系でmountしようとした時に、Filesystemが
腐ることがある他は、特に問題は出てないみたい。ただ、kernel-2.4上だと
ext2fsの方が倍速いと聞いた時はへこんだ。
53: [sage ] 2001/05/04(金)04:30 AAS
>>48
開発中だから仕方ないんだろうが、jfsの意味ねえなあ（ｗ
54(2): 2001/05/04(金)04:37 AAS
>>52
ext2fsはそもそも反則技使ってるようなもんだから、まともなfsと比較
するのも...
# 物理メモリあるだけ全部使って遅延書き込みすりゃ、そりゃ爆速に
# なるわな。
55(2): CCルリたん。 2001/05/04(金)11:48 AAS
>>54
その反則もある意味嬉しい事もあるんだがな。
FreeBSDは物理メモリいっぱいつかうなんて
設定ないの？
56: 48 2001/05/04(金)12:15 AAS
AIX, OS/2 のんは問題ないですよん。
Linux のはログのリプレイまわりがまだ実装されてないだけ。
57: 48 2001/05/04(金)12:17 AAS
あと、JFS for Linux は JFS for OS/2（オープンソース）のコードを
もとにしてポーティング作業されています。AIX for JFS のコードじゃないです。
# まぁ OS/2 のは AIX のを基にしてるから、結果的に AIX のも入ってるだろうけど。
58(1): 名無しさん＠引く手あまた 2001/05/04(金)13:45 AAS
Solaris8ならdefaultでufs loggingが使えるようになった。
やっと人並に。。。
mount optionにloggingを指定するだけでOK。
これで10数分もfsckにつきあわなくて良くなった。
59: 2001/05/05(土)20:34 AAS
>>48
うぁあ、bad superblock といわれてマウントできん・・・
これじゃ使い者にならんがな
60(1): 54 2001/05/06(日)01:26 AAS
>>55
ないねー。
まぁあんな危なっかしいモードなんてあっても(俺は)嬉しくないけど。
61: 2001/05/06(日)02:26 AAS
>>58
細かいことだけど、loggingはSolaris7の11/99あたりから標準だよん。
62(3): インストールラブラブ 2001/05/06(日)03:40 AAS
fsync はジャーナリングなファイルシステムのほうが
はやいのでせうか。
OracleやPostgreSQLのデータファイルの置き場所のファイルシステム
って悩んだりもするのですが。
1. raw -> これってRAIDと愛称わるいしなぁ。
2. ufs -> ふつーすぎる？
3. ufs logging -> 2と比べてどなのかな？？
4. veritas file system -> 2と比べてどなのかな??
63(2): 2001/05/06(日)07:08 AAS
>>62
UFS logging は、log とるぶん write は遅くなるよ。
64(1): 2001/05/06(日)09:37 AAS
VxFS は performance は UFS よか出るってことになっているし、
将来 FibreChannel なんかを使いたいときにもよさそうだけど、
ちと高い。
65(1): 2001/05/06(日)12:47 AAS
>>62
3で運用してるけど、問題になってないな。
更新量が少ないシステムだけどね。
ところでrawとRAIDの相性が悪いってどういうことなんでしょ？
66(1): 2001/05/06(日)13:01 AAS
>>63,64,65
ありがと。
rawとRAIDうんぬんというのは、RAIDあたりまえだったり、
SANつかったりするこのごろだと、果たしてディスクの生のI/Oを
触りたがるrawみたいなものの役割は終わってるのじゃないかという
意図で書きました。
67: 2001/05/06(日)13:36 AAS
>>66
生のI/Oって言うけど、本当に玉を直接ドライブするわけじゃないし・・・。
DBの場合だとカーネルバッファを経由させないことが第一の目的だと
思ってるので、RAWはまだ使われていくと思う。
# もしかして考え方古い？
68(1): 名無しさん＠引く手あまた 2001/05/06(日)15:19 AAS
>>63
ベンチマークしているけど、パフォーマンスの劣化は無視できるほどだよ。
むしろ、VxFSの方が癖があって、ある一定の条件下では深刻な劣化を
起こすけどね。
69: 名無しさん＠引く手あまた 2001/05/06(日)15:27 AAS
>>62
>raw -> これってRAIDと愛称わるいしなぁ
どこのRAID使ってるの？
うちでは問題になったことないよ。
むしろ、ufsにDB置くこと自体が珍しい位。
70(1): 名無しさん＠引く手あまた 2001/05/06(日)15:31 AAS
もっとも、最近ではDBが気を利かせて、カーネルのバッファを
バイパスしてくれるからufsでも問題ないのだろうけどね。
そこが信用できない場合でも、Solaris辺りならforcedirectio
オプションを指定しておけば、バッファリングは解除される。
ジャーナリングの話題じゃないな。
71(1): 2001/05/06(日)22:36 AAS
>>70
raw device の利点は buffer よりも、DB が disk の geometory を直接
把握できるので、data の最適配置を行えること。でも、RAID だと OS
からは hardware 本来の geometory は見えなくなるので、意味が薄くなる
のだ。
って、完全に journaling fs から外れたなぁ。
72: 2001/05/06(日)22:38 AAS
>>68
ある一定の条件下って、小さい file が大量にあって、それを
fseek していったりする場合?
73(3): 2001/05/06(日)22:43 AAS
>>71
RAIDの上にさらに論理ボリュームマネージャなんかをつかってたり
するとさらに薄くなっていくような。
LVMでDBなんて動かすななんて怒んないでちょーだいね。
emc2の手がけたのとか、富士通の手がけたのとかで、最近そういうのが
あったんで。(みんなヤッテルモン！論理だけど)
74(1): 2001/05/06(日)22:54 AAS
>>73
んまぁ、LVM で管理すると、特に FibreChannel で SAN なんかの
環境を組んでいるような場合は面白そうだから、ありといえばあり
なのかも。
そういうものがないのに LVM で管理というのは、単なる performance
bottle neck にしかならないだろうけど…。
75(1): 2001/05/06(日)23:15 AAS
>>74
ボトルネックだけど、バックアップとるのはラクチンだそうです。
76: [sage ] 2001/05/06(日)23:28 AAS
完全に journaling fs から外れるので、とりあえず sage。
>>75
う〜ん、backup はきちんと backup software + DB module でやった
ほうが精神衛生上はいいなぁ。online backup もしたいし。
上下前次1-新書関写板覧索設栞歴
あと 680 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s