1 :
名無しさん@お腹いっぱい。 :
2001/01/14(日) 02:47 いまやるとしたら、みなさんどうします? すごく困ってるんですけど。
2 :
名無しさん@お腹いっぱい。 :2001/01/14(日) 03:02
3 :
名無しさん@お腹いっぱい。 :2001/01/14(日) 19:56
Linux 2.2.18 + ReiserFS で運用していますが、大きなトラブルは 今のところないです。 ただ Quota に対応していない(2.4 向けにはpatch がありますが) のがネックです。また NFS を使う場合にも patch が必要です。
4 :
名無しさん@お腹いっぱい。 :2001/01/14(日) 22:51
上記三つで一番有望なのはどれ?
5 :
名無しさん@お腹いっぱい。 :2001/01/15(月) 11:25
>>2 ext3 を追加。URL は知らん。
>>4 現時点で一番ユーザーが多いのは ReiserFS だと思う。
で、そのまんまなし崩しで ReiserFS のまま逝く、に1兆mips
6 :
名無しさん@お腹いっぱい。 :2001/01/15(月) 11:48
7 :
名無しさん@お腹いっぱい。 :2001/01/15(月) 11:53
IBMのヤツは、1.0が出ている。
OpenAFS:
http://www.openafs.org/ あとさ、LinuxのJFは、2.4でその機能を実装する際の基本骨格だけ、と聞いたが。
実際どうなのかな。
FreeBSDはもう実装しているの?
カーネルが落ちてさえも、ログが残るって話だけど。
8 :
名無しさん@お腹いっぱい。 :2001/01/15(月) 14:04
もっと使ってる人の意見を 聞きたいな。
9 :
名前ついてますか? :2001/01/15(月) 17:47
>>7 LFS使え。ってまだまだ不安定らしいけど。
MetaDataだけじゃなくて、ApplicationDataも残るらしいぞ。
#私の書き込みは BSD Magazine の受け売りです。
10 :
名無しさん@お腹いっぱい。 :2001/01/15(月) 22:00
以前ReiserFSを使ってみたんですが、ある日突然起動に失敗して それっきりです。fsckが要らないってのが売りだったような気がするんですが、 起動スクリプトを書き換えてなかったので、fsckしろと繰り返すだけ のループに陥りました。ReiserFSを使う場合、この辺を書き換える 必要があると思うのですが、どうなのでしょうか。fsckの代わりに 専用ユーティリティがあったように記憶してるんですが。 わたしはその一件以来使っていないのですが。
11 :
3 :2001/01/15(月) 23:53
>>10 /etc/fstab の最後のフィールドを 0 にしていなかったとか
ではないですか?
一応 reiserfsck というプログラムがありますが、デバッグ
用途だったと思います。
ところで、3 で書き忘れたのですが、ReiserFS でごくまれに
ディレクトリの読み出しにやや時間がかかることがあります
(どういう時に発生するのか不明)。
12 :
名無しさん@お腹いっぱい。 :2001/01/16(火) 11:09
>>11 >etc/fstab の最後のフィールドを 0 にしていなかったとか
ではありませんでした。それなら話は早かったのですが、、、
13 :
10=12 :2001/01/16(火) 11:13
普通は/まではReiserFSにはしないんですかね。 ちょっと早計だったのかなあ。
14 :
asm :2001/01/16(火) 17:01
# あまりよく理解してない俺がこんなこと書くのは恐れ多いのだが…
>>7 ,
>>9 システムクラッシュ時にMetadataが破壊されるのを防ぐ手段の一つが
Journaling. で、最近の*BSDに実装されているもう一つの手段がSoft Updates.
JournalingはMetadataの更新ログを取っておくことでクラッシュ後の
ファイルシステムの復旧に役立てようってアプローチで、
Soft UpdatesはMetadataの更新順序を操作することで
いつクラッシュしてもファイルシステムに致命的なダメージが残らない
ようにしようってアプローチ。
Journalingにはfsckが不要になるっていう副産物があるのだが、
Soft Updatesにはそれがない。でも、最近FreeBSD-currentに実装されつつある
snapshotsという機能と組み合わせると、Soft Updatesでも高速rebootが
可能になる。
詳しくは以下のサイトが参考になると思う。
http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ http://www.mckusick.com/softdep/ Soft Updatesを使うとFFSのままでJournalingのような効果が実現できるのが長所。
でも、HDDの容量がテラの域にまで達しようかという現在、ファイルシステムの
再設計が必要な時期に来ていると思う。
LFSってのはNetBSDの次期ファイルシステムの候補で、ファイルシステムそのものを
ログ化してしまおうってもの。でも、まだかなり不安定なようなので、
FFS+Soft Updatesをベースに64ビット化などの拡張を行なったファイルシステムが
先に現れるかもしれない。
# って、こんなもんでよろしいでしょうか? >*BSDの先輩方
# 間違いがあったらツッコミお願いします。
15 :
名無しさん@お腹いっぱい。 :2001/01/16(火) 17:38
>>6 のLinLogFSってのがLinux用のLFS?
16 :
名無しさん :2001/01/17(水) 07:08
>>10 ==12==13
俺はDebianなんだけど、Debianではrootファイルシステムは
強制的にfsckにかけるようになってるので、それで引っかかった。
grep fsck /etc/init.d/*
とかやってみ。
17 :
名無しさん@お腹いっぱい。 :2001/01/17(水) 19:34
Solarisなら7から対応してます。 /etc/vfstabのマウントオプションのところに loggingと入れるだけでOK。 特に問題なく動いてます。
18 :
10=12=13 :2001/01/17(水) 22:38
>>16 なるほど。
再度挑戦する時に調べてみます。
19 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 03:56
>> 14 64bit化ってなんでしょ? Linux以外のほぼ全てのUNIXは、とっくの昔に64bit対応してたんだけど。 open64 系のシステムコールのことかな? BSD系だとあれ使わなくても元から64bitアクセスできるので問題ないんよ。
20 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 04:30
kernel 2.4.1-pre4 で ReiserFSが取り込まれました。
21 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 04:36
みんな勇気あるね。私はびびりなので新しいものには手が出せません。
22 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 04:40
IBM, SGIの立場は?
23 :
名無しさん :2001/01/18(木) 07:45
24 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 15:19
25 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 15:48
26 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 15:56
27 :
名無しさん@お腹いっぱい。 :2001/01/18(木) 16:54
>>20 では、kernel 2.4.1からはパッチ当てなくてよくなるんですね。
私はpre系を試す勇気はないです。
(2.4.1-pre6なんかはファイル名に'dontuse-'ってprefixが…)
>>24 そのうち誰か作るとおもいますけどね。
28 :
asm :2001/01/18(木) 17:31
29 :
名無しさん@お腹いっぱい。 :2001/01/25(木) 10:11
age
30 :
名無しさん@お腹いっぱい。 :2001/01/27(土) 12:44
31 :
名無しさん@お腹いっぱい。 :2001/01/27(土) 13:01
結局どれ使えばいいんだろ。 Debianでapt一発でなんとかなんない?
32 :
名無しさん@お腹いっぱい。 :2001/02/06(火) 15:43
age
33 :
名無しさん@お腹いっぱい。 :2001/02/07(水) 23:56
>>31 Debianって聞いた話だと、Cライブラリをマシンを動かしながら
アップグレードできるんでしょ?
なら、ファイルシステムもやりかねないな。
そうならすごすぎる
34 :
名無しさん@お腹いっぱい。 :2001/02/08(木) 01:36
>Debianって聞いた話だと、Cライブラリをマシンを動かしながら >アップグレードできるんでしょ? それってRedhat系ではできないことなの? 要するにコンパイルしなおす羽目になるもの(バイナリ)を 同時にダウンロードしてインストールすればいいだけのような。
35 :
名無しさん@お腹いっぱい。 :2001/02/08(木) 12:40
>34 やったことない。 GnoRPMでは、glibcはアップグレード対象外になっているけど・・
36 :
名無しさん@お腹いっぱい。 :2001/02/08(木) 13:32
>>34 おれは何度もしてる。
glibcアップグレードした後は shutdown 時に umount できないような
37 :
名無しさん :2001/03/01(木) 03:06
あげ
38 :
名無しさん@お腹いっぱい。 :2001/04/27(金) 10:05
ReiserFSってdump/restoreで問題ないの?
39 :
名無しさん@お腹いっぱい。 :2001/04/28(土) 01:48
手元の 2.2.19 + ReiserFS-3.5.32 には以下のツールがついている。 ただ自分は mkreiserfs しか使ったこと無し。 dumpreiserfs mkreiserfs reiserfsck resize_reiserfs
40 :
名無しさん@お腹いっぱい。 :2001/04/28(土) 05:57
decのAdvfsって性能はどうでしょうか?
41 :
仕様書無しさん :2001/05/01(火) 09:14
LFS age。 現状 NetBSD-current LFS はまだ mmap() 周辺が痛い感じ。 mmap() がなければそこそこ使える…と思う。
42 :
名無しさん@お腹いっぱい。 :2001/05/02(水) 16:38
SGI XFSアゲ
43 :
名無しさん@お腹いっぱい。 :2001/05/02(水) 19:42
> LFS age。 mmap on LFS が壊れたのは UBC のせい (原因も分かっているけど, 直すのが かなり手間なのでまだ直ってない) なので, LFS を真面目に使うなら UBC 統合直前の -current が良いかもしれない.
44 :
名無しさん@お腹いっぱい。 :2001/05/02(水) 22:18
Solaris の UFS logging がなにも考えずにできて一番楽…。
IBMのJFS1.0が2.2.x系にも対応しててカーネルパッチになってたんでビルドしてみた。 誰か問題起きた人いる? 骨格はもともとIBMが使ってたロジックだろうからデータが壊れたりしないかなとは思ってるんだけど、心配。
46 :
名無しさん@お腹いっぱい。 :2001/05/02(水) 22:47
IBMのJFS1.0が2.2.x系にも対応しててカーネルパッチになってたんでビルドしてみた。 誰か問題起きた人いる? 骨格はもともとIBMが使ってたロジックだろうからデータが壊れたりしないかなとは思ってるんだけど、心配。
ごめん。ごめんよ・・・ そんな豚無くても・・・
48 :
名無しさん@お腹いっぱい。 :2001/05/04(金) 01:58
>>46 jfs FS を mount したまま電源きって再起動してみ。
filesystem dirty と表示されて、mkfs するまで二度とその fs をマウントできなくなるから。
49 :
名無しさん@お腹いっぱい。 :2001/05/04(金) 02:08
IBM JFS や SGI XFS とかだと書き込みだけでなくて
読み出しのスピードが上がっているの?
古典的な UNIX FS の系列だとディレクトリ内のファイル数が
増加すると ls のスピードも落ちるみたいなんだけど。
>>46 それって OS/2 とか AIX でもなるの?
JFS for Linux だけならまだいいんだけど。
50 :
49 :2001/05/04(金) 02:13
51 :
CCルリたん。 :2001/05/04(金) 02:21
>>49 の下
大丈夫だよ。以前AIXがあったけど、停電でも耐えたから。
52 :
Mary β :2001/05/04(金) 03:55
>>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の方が倍速いと聞いた時はへこんだ。
>>48 開発中だから仕方ないんだろうが、jfsの意味ねえなあ(w
54 :
名無しさん@お腹いっぱい。 :2001/05/04(金) 04:37
>>52 ext2fsはそもそも反則技使ってるようなもんだから、まともなfsと比較
するのも...
# 物理メモリあるだけ全部使って遅延書き込みすりゃ、そりゃ爆速に
# なるわな。
55 :
CCルリたん。 :2001/05/04(金) 11:48
>>54 その反則もある意味嬉しい事もあるんだがな。
FreeBSDは物理メモリいっぱいつかうなんて
設定ないの?
56 :
48 :2001/05/04(金) 12:15
AIX, OS/2 のんは問題ないですよん。 Linux のはログのリプレイまわりがまだ実装されてないだけ。
57 :
48 :2001/05/04(金) 12:17
あと、JFS for Linux は JFS for OS/2(オープンソース)のコードを もとにしてポーティング作業されています。AIX for JFS のコードじゃないです。 # まぁ OS/2 のは AIX のを基にしてるから、結果的に AIX のも入ってるだろうけど。
58 :
名無しさん@引く手あまた :2001/05/04(金) 13:45
Solaris8ならdefaultでufs loggingが使えるようになった。 やっと人並に。。。 mount optionにloggingを指定するだけでOK。 これで10数分もfsckにつきあわなくて良くなった。
59 :
名無しさん@お腹いっぱい。 :2001/05/05(土) 20:34
>>48 うぁあ、bad superblock といわれてマウントできん・・・
これじゃ使い者にならんがな
60 :
54 :2001/05/06(日) 01:26
>>55 ないねー。
まぁあんな危なっかしいモードなんてあっても(俺は)嬉しくないけど。
61 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 02:26
>>58 細かいことだけど、loggingはSolaris7の11/99あたりから標準だよん。
62 :
インストールラブラブ :2001/05/06(日) 03:40
fsync はジャーナリングなファイルシステムのほうが はやいのでせうか。 OracleやPostgreSQLのデータファイルの置き場所のファイルシステム って悩んだりもするのですが。 1. raw -> これってRAIDと愛称わるいしなぁ。 2. ufs -> ふつーすぎる? 3. ufs logging -> 2と比べてどなのかな?? 4. veritas file system -> 2と比べてどなのかな??
63 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 07:08
>>62 UFS logging は、log とるぶん write は遅くなるよ。
64 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 09:37
VxFS は performance は UFS よか出るってことになっているし、 将来 FibreChannel なんかを使いたいときにもよさそうだけど、 ちと高い。
65 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 12:47
>>62 3で運用してるけど、問題になってないな。
更新量が少ないシステムだけどね。
ところでrawとRAIDの相性が悪いってどういうことなんでしょ?
66 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 13:01
>>63 ,64,65
ありがと。
rawとRAIDうんぬんというのは、RAIDあたりまえだったり、
SANつかったりするこのごろだと、果たしてディスクの生のI/Oを
触りたがるrawみたいなものの役割は終わってるのじゃないかという
意図で書きました。
67 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 13:36
>>66 生のI/Oって言うけど、本当に玉を直接ドライブするわけじゃないし・・・。
DBの場合だとカーネルバッファを経由させないことが第一の目的だと
思ってるので、RAWはまだ使われていくと思う。
# もしかして考え方古い?
68 :
名無しさん@引く手あまた :2001/05/06(日) 15:19
>>63 ベンチマークしているけど、パフォーマンスの劣化は無視できるほどだよ。
むしろ、VxFSの方が癖があって、ある一定の条件下では深刻な劣化を
起こすけどね。
69 :
名無しさん@引く手あまた :2001/05/06(日) 15:27
>>62 >raw -> これってRAIDと愛称わるいしなぁ
どこのRAID使ってるの?
うちでは問題になったことないよ。
むしろ、ufsにDB置くこと自体が珍しい位。
70 :
名無しさん@引く手あまた :2001/05/06(日) 15:31
もっとも、最近ではDBが気を利かせて、カーネルのバッファを バイパスしてくれるからufsでも問題ないのだろうけどね。 そこが信用できない場合でも、Solaris辺りならforcedirectio オプションを指定しておけば、バッファリングは解除される。 ジャーナリングの話題じゃないな。
71 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 22:36
>>70 raw device の利点は buffer よりも、DB が disk の geometory を直接
把握できるので、data の最適配置を行えること。でも、RAID だと OS
からは hardware 本来の geometory は見えなくなるので、意味が薄くなる
のだ。
って、完全に journaling fs から外れたなぁ。
72 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 22:38
>>68 ある一定の条件下って、小さい file が大量にあって、それを
fseek していったりする場合?
73 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 22:43
>>71 RAIDの上にさらに論理ボリュームマネージャなんかをつかってたり
するとさらに薄くなっていくような。
LVMでDBなんて動かすななんて怒んないでちょーだいね。
emc2の手がけたのとか、富士通の手がけたのとかで、最近そういうのが
あったんで。(みんなヤッテルモン!論理だけど)
74 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 22:54
>>73 んまぁ、LVM で管理すると、特に FibreChannel で SAN なんかの
環境を組んでいるような場合は面白そうだから、ありといえばあり
なのかも。
そういうものがないのに LVM で管理というのは、単なる performance
bottle neck にしかならないだろうけど…。
75 :
名無しさん@お腹いっぱい。 :2001/05/06(日) 23:15
>>74 ボトルネックだけど、バックアップとるのはラクチンだそうです。
完全に journaling fs から外れるので、とりあえず sage。
>>75 う〜ん、backup はきちんと backup software + DB module でやった
ほうが精神衛生上はいいなぁ。online backup もしたいし。
77 :
名無しさん@お腹いっぱい。 :2001/05/08(火) 00:06
>>73 DB、特にOracle使う時は、VxVM使うのは常識だぞ。LVMの機能は知らんが
VxVMと同じならば必須と思われ。
Oracle DBをrawで扱うなら、2GB毎に切らないとならない。64bitならば
その制限は無いことになっているが、やはりパフォーマンス上、2GBで
切るのが常道。
RAIDが何10GBもある場合、Solarisだとpartition数の制限から2GB単位に
切ってしまうと16GBしか活用できぬ。
VxVMで2GB以下のVolumeを作成しないとな。
78 :
名無しさん@お腹いっぱい。 :2001/05/08(火) 00:06
>>73 DB、特にOracle使う時は、VxVM使うのは常識だぞ。LVMの機能は知らんが
VxVMと同じならば必須と思われ。
Oracle DBをrawで扱うなら、2GB毎に切らないとならない。64bitならば
その制限は無いことになっているが、やはりパフォーマンス上、2GBで
切るのが常道。
RAIDが何10GBもある場合、Solarisだとpartition数の制限から2GB単位に
切ってしまうと16GBしか活用できぬ。
VxVMで2GB以下のVolumeを作成しないとな。
79 :
名無しさん@お腹いっぱい。 :2001/05/08(火) 00:08
ごめん、2つもはいってしまった
80 :
名無しさん@お腹いっぱい。 :2001/05/08(火) 13:00
>>43 UBC その他の新作ドライバも捨て難いので最新 -current でごーごー ;_;
私は厨房なんでこのへんは治ることを祈ることぐらいしかできない。
巨大ボリュームになると fsck にかかる時間が無視できないから
LFS に期待大なのね。
81 :
名無しさん@お腹いっぱい。 :2001/05/08(火) 22:11
じゃーなるあげ
82 :
名無しさん@お腹いっぱい。 :2001/05/14(月) 12:58
lfs_cleanerd がデフラグなんかもやってくれると嬉しいな。
83 :
名無しさん@お腹いっぱい。 :2001/05/17(木) 12:48
LFSあげ。 セグメント境界==ストライプ境界ができる日はいつかな…。
84 :
名無しさん :2001/05/25(金) 18:06
UBCパッチの報告がありましたね…。 LFS復活の日は近い? 期待あげ
85 :
名無しさん@お腹いっぱい。 :2001/06/01(金) 23:23
age
86 :
名無しさん@お腹いっぱい。 :2001/06/07(木) 19:50
age
87 :
名無し :2001/06/20(水) 05:16
あげ
88 :
名無しさん@お腹いっぱい。 :2001/06/23(土) 01:19
FreeBSD Press に Usenix のジャーナリングと soft update を 比較した論文の翻訳が出ているのであげ
89 :
名無しさん@お腹いっぱい。 :2001/06/26(火) 14:26
>>14 Metadataってなんですか?教えていただけませんか。
>>89 データ(この場合はファイルの中身)を管理するためのデータ。
superblockとか、ファイルインデクス、占有マップなど。
(ディレクトリエントリも含まれることがある)
91 :
名無しさん@お腹いっぱい。 :2001/06/29(金) 11:22
June 28, 2001:
IBM is pleased to announce the v 1.0.0 release of the open source
Journaled File System (JFS), a high-performance, and scalable file
system for Linux.
http://oss.software.ibm.com/jfs
92 :
名無しさん@お腹いっぱい。 :2001/06/29(金) 14:32
ReiserFS 使ってるよん。 Debian だけど残念ながら、apt でFS変換っつーのは無いね。 ext3 は既存の ext2 からバージョンアップできるらしいが、ReiserFS は無理みたい。 んで、ReiserFS はやっぱ読み込みが速いよ。ext2 はシーク音が 「ゴガガガガ、グフッ」って感じだったけど、「ジジジジジ」って いかにもヘッドが振れてない感じがするんだよね。 逆に書き込みは遅くなったが。
93 :
名無しさん@お腹いっぱい。 :2001/06/30(土) 03:59
まったくヴァカは死ねば?
94 :
名無しさん@お腹いっぱい。 :2001/07/10(火) 00:30
reiserfsは不具合あるみたいですね xfsが完璧そうで期待age
95 :
名無しさん@お腹いっぱい。 :2001/07/10(火) 00:33
んー、おれは JFS に期待してるんだけど。 もちろんXFSにもReiserFSにもがんばって欲しい。
97 :
名無しさん@お腹いっぱい。 :2001/07/14(土) 00:16
99 :
名無しさん@お腹いっぱい。 :2001/07/14(土) 07:46
>>55 >>60 あるよ?FFFSで非同期モードでマウントしたらクリチカルな操作をしても
遅延モードのままバッファリングするからext2fsと勝負できる位には
速くなるっす。怖いんで使わないけど。LFSとかにもあるかどうかは
不明。UPS買ったら非同期モードにしようと決心してもう1年近くに
なるなぁ。早く買わなきゃ…。
100 :
99 :2001/07/14(土) 09:24
そういや、最近はsoft-dependenciesがサポートされて、安全に 遅延書き込みできましたね。これでも多少は速くなるので、 まずはこれを試してみようっと。 どんどんジャーナリングFSから離れていくんで下げ。>_<
101 :
名無しさん@お腹いっぱい。 :2001/07/14(土) 12:56
>>99 4.3BSD(NEWS-OS)を使ってたとき、
FFSのasync mount使ってたけど、
kernel panicして落ちたときに修復困難なくらい
壊れてくれたんで信用してないんだけど、
FreeBSDのは改善されてるのかなぁ?
ext2fsだとあまりひどいことにはならないので
ディフォルトasyncにできたんだろうな。
102 :
99 :2001/07/14(土) 16:57
>>101 今でもasyncはヤバイと思われ。UPS入れててもpanicすると逝けますネ。
というわけでNetBSDでsoftdepつかってみました。いけてます。
うちはRAID5の上に構築してるFFSなので、ファイル操作が死ぬ程遅いんす。
ただでさえ遅いソフトでやるパリティ計算を同期のために毎回待つので
当然なんすけどね。んで、softdep入れてやると一瞬で、おお〜。
理論的には当然なんだけど、プロジェクトディレクトリとかrm -rf
したら一瞬でプロンプトに戻ってきてビビリました。まるでwand of
cancelationをmagic holding bagに突っ込んだときのように、しばらく
キョロキョロとプロジェクトディレクトリを探して辺りcdやlsして
しまいました。そんなわけで*BSDな人は是非トライ♪
103 :
名無しさん@お腹いっぱい。 :2001/07/15(日) 00:57
ReiserFSとかJFSとかって*BSDに移植できないんかな。
104 :
名無しさん@お腹いっぱい。 :2001/07/15(日) 08:19
RDBMSの領域をおいても意味ないような気が・・・ もともとDBってのはリカバリログ域があるんだからほっときゃいーんです。 しかし、4重化するほど大切なのであれば、 リカバリログ域をそういうところに置くとよいでしょう。 表・インデックスをそういうところに置く必要はまったくなし。
105 :
名無しさん@お腹いっぱい。 :2001/07/15(日) 08:19
いまごろジャーナルですか?プププ UNIXて遅れてるね。 OS/390は昔ッからそんなもんタダでついてますよ。
106 :
名無しさん@お腹いっぱい。 :2001/07/15(日) 09:07
>>105 ハァ? UnixWare だって IRIX だって以前からファイルシステムはジャーナル化されていると思うけど
ジャーナルファイルシステムが、ちゃんと 想定している種類の破壊を防いでいるという ことをテストするにはどうすればよいでしょう。 もしくはそういったテストをするソフトとか スクリプトはありますか?
109 :
名無しさん@お腹いっぱい。 :01/10/05 17:50
>>108 ディスクがごりごりいってるときに、いきなり電源抜いてみれば?
それでは、本当にハードディスクがヘッドクラッシュを してしまいかねません。ハードの故障までは回復 できないと思います。RAIDではないから。
111 :
食いだおれさん :01/10/06 00:18
>>101 > 4.3BSD(NEWS-OS)を使ってたとき、
> FFSのasync mount使ってたけど、
(略)
> FreeBSDのは改善されてるのかなぁ?
soft updateは、async writeとは違う。
transaction commitしていい時までqueue(めちゃ短い)する手法。
高健全性度
journaling > soft update > sync write > async write
112 :
名無しさん@お腹いっぱい。 :01/10/29 13:09
結局ReiserFSはダメダメってことで
113 :
名無しさん@お腹いっぱい。 :01/10/29 13:33
>>111 あと依然として SoftUpdate には fsck が必要だね
114 :
風の谷の名無し :01/11/03 16:37
XFSはいいぞー。マイナーだけど。 漏れのノートで使ってるよ。アフォKDEのせいでリセットしまくりだけど 一度も飛んだことないっす。XFSマンセー。 (でも開発メンバーリストラされたらしい・・・)
115 :
名無しさん@お腹いっぱい。 :02/01/29 11:40
116 :
名無しさん@お腹いっぱい。 :02/01/29 11:49
>110 今売ってるハードディスクがそんなんで飛ぶとは思えないなぁ。 それに、電源切るのがいやならリセットでもいいだろ。
>>116 漏れもそう思っていたが、ごく最近実際そうなった。
買って半年の○BMのHDD…。
119 :
名無しさん@お腹いっぱい。 :02/01/29 20:14
オレはNTFS使う
120 :
名無しさん@お腹いっぱい。 :02/01/29 21:35
>>111 sync > softupdate
ではないの?
121 :
名無しさん@お腹いっぱい。 :02/01/29 21:38
>>113 FSCKかけないFSなんぞ怖くてつかえん。
>>121 昔の本には、定期的にfsckするのは媒体異常をチェックする意味もある、て書いてあるよね。
ふだん使ってない領域をアクセスしたら壊れてた・・・とかならないように。
でも、現代のHDDだったら不要では?て議論はあっても良いと思う。
ディスクのライトキャッシュのフラッシュはまじめにやってるんだろうか? ジャーナリングの場合は 1,ログの書き込み 2,ディスクキャッシュのフラッシュ 3,ダーティなデータを適当な順序で書き込み となると思うが softupdateの場合はどうなりますか?
>>124 ディスクのキャッシュのフラッシュはどこに入るんでしょうか?
softupdateは順序に対する制約が多いので、ディスクドライブが賢くなると ジャーナリングに対して不利になります。 Solarisは(多分)それを見越してsoftupdateではなく、ジャーナリングを 使っていると思われます。
128 :
仕様書無しさん :02/03/09 16:42
保守あげしまーす
129 :
名無しさん@お腹いっぱい。 :02/05/22 07:57
salvage sage ;D NetBSD 1.6 + LFSv2 coming soon!
とりあえず保全sage
132 :
名無しさん@お腹いっぱい。 :02/08/04 22:46
CPUのアイドルの時に、定期的に裏で、プライオリティ最低で、 ハードディスクをRAWデバイスとして、トラックを順番に読んでみて 磁気記録のECCが壊れてないかどうかを見にいかせるオプションが 欲しいなぁ。FSCKなどは、今ファイルとして使っているブロック しか対象としないし、しかもリンク情報しか触らないから中身が 壊れていても読み出すまでは判明しない。
JFS4BSDは着々、のようですな
>>132 FreeBSD の diskcheckd が正にそれでは。最初は base に入ってたけど、今は ports に移動されている。(sysutils/diskcheckd)
>>125 難しくてあまり分からなかったけど、ext2系は怖いな。
136 :
名無しさん@お腹いっぱい。 :02/08/14 19:33
あと、ext2のfsckって、Solaris ufsのfsckとかに比べて、妙に遅いし....
んで、ext3は単にext2にジャーナル付け足しただけなんで、fsckは必要なく なっているものの (なぜか数回のbootごとにfsckかかるけど) 壊れかたに 違いはなく、怖〜いfsのまま…。まあ、Linux界にはもっと怖いReiserFS なんてシロモノもありますけど。 Linuxで原理的にまともなfsというとXFSがJFSってことになりますけど、 どちらも実装はまだちょっと未成熟なので、実運用時の安定性ではext2&ext3 に劣るようです。
139 :
名無しさん@お腹いっぱい。 :02/08/15 15:49
速度的にはext2がなんだかんだで一番だったな。 ext3にするとちょっと遅くなるけど。個人的にはXFS使ってます。 ReiserFSは小さいファイルが沢山あるときは速いんですが、エロビデオなんかを扱うような 場合は不利になりますね。あとNFSするときにも不具合がありますし…(VFS絡み) XFS/LinuxがACLを実装して運用できるようになればますますおもしろい。
140 :
名無しさん@お腹いっぱい。 :02/08/15 20:29
141 :
名無しさん@お腹いっぱい。 :02/08/25 21:46
ファイルシステムを取り替えたら、Linuxのスワップファイルのサイズの 1個あたり2GBという制限が取り除けますか? 40GBのスワップを とるのに20個の領域を取るのが美しくないし、あまり良くないです。 できれば単一のドライブに40GBのスワップ領域を1つデンととって 終わりにしたいのですがぁ。。。 IA-64だと、スワップの大きく取れないシステムなんて、意味ないですから。
スレッドタイトルが読めない方がいます
143 :
名無しさん@お腹いっぱい。 :02/08/26 03:48
JFFS2マンセー
144 :
名無しさん@お腹いっぱい :02/08/26 07:00
>>141 主記憶はどのぐらい実装するの? こっちのほうが興味あるなぁ
XFS良いよね。 Indogo2使っていた時はぜんぜん思わなかったけど, 「linux(ext2)触りだしてなんでこんなに悲惨な事になるのよ!!」 しまいには, 「またかよ…。」 XFS for Linuxが安定して運用できるレベルになることを望む。 #今も良い感じなんだけど,稀におかしくなるね。
>>145 XFS、希にと優香、結構おかしくなります。
XFS or JFSが枯れるまではext3使わざるを得ないと思います。
>>146 使わないといつまでも枯れないですね。。
すいませんがお前らBFSも語ってください。 漏れはわからん・・・(;´д`)スマン
OpenBFS を NetBSD に移植して欲しい MIT-style license だし
NetBSD の lfs_cleanerd が数時間 segment clean し続けたときはあせった ログに /netbsd: fs_segclean: not cleaning segment 588: 8192 live bytes last message repeated 19 times lfs_cleanerd[509]: lfs_segclean: segment 588: Device busy last message repeated 187 times こんな感じで message 出まくり 2G の partition で /usr/pkgsrc に使っているんで必要なファイルを backup した後 #rm -rf * でファイル消したら止まったけど, そんなに file system がぐちゃぐちゃだったのか
>>150 最近のcurrentってLFSフツーに使えるんでしょうか?
話を見てると怖くて試せないす。
>>151 こっちは 1.6 なんで current はどうか分からないけど
working directory のようなそれほど重要でない場所ではについては
それなりには使えると思う
書き込み速度はやはり速いし
>>150 は LFS を NFS で export して
NFS client の方から pkgsrc を compile しまくったときに現れた message
で file system がぐちゃぐちゃというのは directory などがぐちゃぐちゃという意味ではなくて
segment 自体が相当虫食い状態になったんだろうなということ
単なる推測で言った言葉です
>>152 なるほど。pkgsrc くらいだったら壊れて問題ないし、
私も試してみようかな。thx
>>154 ext3ジャーナリングファイルシステム
は
/**ファイルシステム総合スレ その1**/
に統合されたんだ。
むやみに貼るな。
156 :
名無しさん@お腹いっぱい。 :02/11/15 03:55
ジャーナルファイルは二度書き込むらしいので遅いのではありませんか? RAID5+UPSなどを組んでいるディスクを使う場合には、 ジャーナルファイルでなくても ext2 のようなファイルシステムで十分 でしょうか?
>>156 全ての書き込みをsyncでやると遅くなるので、
大抵はジャーナルだけsyncで書き他を全てasyncで書いている。
RAID5で保護される内容とジャーナルファイルシステムで保護される内容を理解していないと思われ。
RAIDはディスクの破壊に対処するシステムで、
ジャーナルファイルシステムは予期せぬシステムダウンによるファイルシステムの破壊に対処するシステム。
UPSを使えば安全と思うかも知れんが、kernel panicなど電源以外の要因でシステムダウンすることは往々にしてありえる。
(^^)
(^^)
160 :
名無しさん@お腹いっぱい。 :03/03/18 20:00
LFS
(^^)
あぼーん
あぼーん
あぼーん
sage
166 :
名無しさん@お腹いっぱい。 :03/07/01 15:20
reiserfs v4はどうなのよ? 犬糞ネイティブだけあって糞なのか?
あぼーん
168 :
名無しさん@お腹いっぱい。 :03/08/04 01:02
GRUBのUTF2対応はまだー?
あぼーん
170 :
名無しさん@お腹いっぱい。 :03/09/07 01:53
ぬるぽ
171 :
名無しさん@お腹いっぱい。 :03/09/10 13:24
名前がカッコイイから使おうかな・・・・・ じゃーなりんぐふぁいるしすてむ・・・・ っでなににつかうの??
175 :
名無しさん@お腹いっぱい。 :04/10/06 11:44:28
176 :
名無しさん@お腹いっぱい。 :04/12/04 03:33:49
BSDファイルシステム使いたいんだけども?
どうぞ?
PC-UNIXで動くまともなファイルシステムってないの?
あります
ありません
まともな、の定義によるね。linux xfs 程度でまともと言えるなら、ある。
>>178 OS関係ないだろ。
愚痴るなら「PCで動くまともなファイルシステムってないの?」ですな。
っつーか仮にファイルシステムに問題があるとしても、
その問題を顕在化させたユーザに責任があるっていう。
FreeBSD の FFS なんて他の unix と比べたって熟しているものの 一つじゃないのかな。 まあ 5系の UFS2 になると熟度はだいぶ落ちるのかもしれないけど。
XFSマンセー。 LVMでパーティションを小さくできないのが唯一の悩みだけど。
185 :
age :2005/11/18(金) 01:00:07
さいきんはどうなのよ
reiserfs はかなり速いよ。データベース用途によか。
U33 Linuxカーネル座談会/2 で、NTT の人が評価してみたら 確かに ReiserFS だけ異常に速かったんだけど、よくよく 調べたらジャーナリング処理をサボっているところがあって、 そこをちゃんと障害回復できるように直してみたら、Linux の他のファイルシステムと同じ性能になっちゃったって話が あったらしいよ。りょうせいさんの Tiki に載ってる。
結局のところ、今も Linux は(どのファイルシステム使ってても) file system 関連は信用するなってことかな?
Windowsが一番いいな
UFS Journaling って見込みはどうなん?
見込みってのをどういう意味で言ってるのかが分からないけど、 UFS journaling って、まあ ext3 みたいなもんなので、いまどき ちょっと古くさいなあって感じはあるんじゃないの? ないよりはマシだけどさ。 できれば、ディレクトリが肥大しても性能低下がなくて (UFS_DIRHASH はカーネルのメモリを無駄に使うのがちょっと駄目)、あと、利用中に resize できたりするジャーナリングファイルシステムが欲しいと思う。
結局 FreeBSD に JFS やら XFS を porting するって 話は停滞中なのかな?
FreeBSDそのものが停滞中です
>>192 よく分からないけれど、reiserfsは読めるようになったみたい。
見たら
>>191 がとても笑えることを書き込んでいた
久しぶりに見にきたんだが NTT のアレがまるで話題になってないな。 実装を間違えてなければかなりよさげなんだが、使ったやついる?
> 実装を間違えてなければかなりよさげなんだが、 間違えるとか以前に、GCがまだ実装されていません。
自動GCは実装しないとかほざいたしな
>>199 それって、普及させるつもりはありませんって事だよね?
NTTのやつって開発者の話聞く限り、自動でバックアップ作ってくれるファイルシステムを作りたくて出来たもののような気がする。 バックアップなんだからGCで勝手に削除されるのは逆に困るっていってたよ。
VMS の履歴保存ファイルシステムみたいなものかな? しかし自動でバックアップって、そんな簡単に バックアップ部分を展開したり引き出したりできるんかいな?
>202 日時指定でread onlyマウントできるよ。 なんかログのヘッダ領域にいろいろコメント埋め込んで、そのコメント使ってviewの指定ができるようにしたいらしい。
ディスクフルでシステムが止まるの問題がある限り使い物にならない
>204 作者の真意まではしらんが 通常の汎用のfile system と思うとそうなるけど 別な使い方を想定しているんじゃないのか?
206 :
名無しさん@お腹いっぱい。 :2006/05/14(日) 12:36:34
ジャーナリングが SoftUpdate よりも優れている点って何?
snapshotをちゃんと取ってくれれば良いんと違うか?
>>201 ここの話ってVxFSでいいような気がする(高いけど)
208 :
名無しさん@お腹いっぱい。 :2006/05/31(水) 20:55:31
FreeBSDのXFSまだー?
209 :
名無しさん@お腹いっぱい。 :2006/06/01(木) 19:03:14
JFSが最強もたまには思い出してあげて下さい。
210 :
名無しさん@お腹いっぱい。 :2006/06/01(木) 19:10:33
>>208 今のところ(永久に?)読むだけ
むしろFreeBSDがイラ(w
FreeBSD-currentにxfsのwriteサポート入ったね 動くかどうか知らんけど
geom でジャーナルやるとか言ってるな.
214 :
名無しさん@お腹いっぱい。 :2006/07/28(金) 16:10:30
redhatでXFSが標準で入れられないのはどうかと思われ やっぱりSUSEですよ
>>214 そうなの? Fedoraでは行けるから同じかと思ってたよ。
freebsd-fs ML 眺めてみたら gjournal ってのが >213 の話かな? 8/9 の post で final patch キボンとか言ってるね @ 7-current
217 :
名無しさん@お腹いっぱい。 :2006/10/11(水) 23:22:32
219 :
名無しさん@お腹いっぱい。 :2006/10/13(金) 22:53:30
ZFSでいいじゃん。 もうすぐホットスペアやダブルパリティもサポートされる
>>219 凄く期待してるんだが、ホントに信頼できるのかよくわからない。
逆説的だがみんなが使って、データ飛ばして、
データが飛ぶ確率出してみないことには信頼性云々の話が出来ない。
221 :
名無しさん@お腹いっぱい。 :2006/10/14(土) 18:22:47
とりあえずさ、2次ストレージやバックアップストレージとして使うと いいんじゃない?
222 :
名無しさん@お腹いっぱい。 :2007/01/22(月) 10:06:43
ディスクドライブのコントローラボードに搭載されるキャッシュが 32MBとかそれ以上とかにでっかくなって、さらにコントローラ内で コマンド順を入れ替えて効率的な読み書きをするようになってくると、 いったいどこまでの情報が本当にディスクに書き込まれたのか わかんなくなって、ジャーナル自体も本当に書き込まれたか 怪しくなってくる気がするんだけど、そんな心配してしまうのは 俺が素人だからですか?
なるほど、SCSIやSATAではFUAというコマンド(機能?)があるから これを使って確実に書き込ませるということが出来るんですね。 適当なタイミングでフラッシュしてやれば書き込み順も保証できる、と。 PATAではFUAを提供していないにもかかわらず、最近のPATAドライブ では書き込み順を変更している場合があって、しかもドライブ側の キャッシュに入った時点で書き込み完了通知を返してしまう、 ということなんですね。
うぉ、FUAってフラッシュを強制させるコマンドじゃなかったのか。
http://pc.watch.impress.co.jp/docs/2004/1220/maxtor.htm NCQは、ホスト側から送られてくるコマンドを、ドライブ側で実行順位を
並び替えて最適化し、高速化をはかる技術。パラレルインターフェイスでは、
デバイス側からコマンドの終了を通知する手段がなく、実現できなかった。
FUAは、電源障害時のデータ消失を防止する機能。通常のHDDでは、
Writeコマンドの終了通知は、HDDのバッファに書き込まれた時点で通知される。
ディスクへは書き込まれていないため、この時点で停電が起きた場合は、
バッファ内のデータは失われる。FUAでは、データをディスクへ書き込んだ
時点で終了通知をホストへ返すため、停電などによるデータ消失の可能性
を軽減できるという。
単なる write cache enable /disable とはどう違うの?
228 :
名無しさん@お腹いっぱい。 :2007/01/24(水) 01:46:07
まぁ、ジャーナリングなんか止めて、ZFS使えと。
ZFS って Solaris 以外だと何に移植されてるんだろう。
FreeBSD , FUSE/Linux, MacOSX
Linux は FUSE かぁ・・・ いや、単に「ファイルシステムはカーネルスペースで」 っていう固定観念から逃れられていないオレが 古いだけで拒絶しているのかも知れんが。
>>231 マイクロカーネルOSならともかく、モノリシックカーネルOSならその認識は正しい。
FUSEは読み書きできて可搬性が広がるっていう程度。常用するものじゃない。
233 :
名無しさん@お腹いっぱい。 :2007/01/24(水) 23:55:27
234 :
名無しさん@お腹いっぱい。 :2007/02/21(水) 14:39:11
>>224 > PATAではFUAを提供していないにもかかわらず、最近のPATAドライブ
> では書き込み順を変更している場合があって、しかもドライブ側の
> キャッシュに入った時点で書き込み完了通知を返してしまう、
> ということなんですね。
書き込み順変えられるのはSATAIIの方だろ(NCQ)
あとPATAはキャッシュをフラッシュできるのでこの点はOSの努力不足
ATA
http://community.osdev.info/index.php?ATA 0xe7 No-Data FLUSH CACHE
235 :
名無しさん@お腹いっぱい。 :2007/02/21(水) 17:45:24
WAFLはいいらしいが高いし どうよ
236 :
名無しさん@お腹いっぱい。 :2007/02/22(木) 23:10:33
237 :
名無しさん@お腹いっぱい。 :2007/03/14(水) 16:00:58
閑話休題
238 :
名無しさん@お腹いっぱい。 :2007/07/28(土) 22:21:56
それはさておき
一体いつになったらNTFSを超えるFSが出てくるのだろうか。 それともオプソ連中には荷が重いか。
そんな餌で…
241 :
名無しさん@お腹いっぱい。 :2007/08/25(土) 21:38:40
ZFSでいいじゃん。
242 :
名無しさん@お腹いっぱい。 :2007/08/25(土) 23:03:03
「ジャーナリズム宣言。」 extended3
NTFSは変に細かいところで多機能だからなあ 複数ストリームなんて誰が使ってるんだと思ったら、 これが意外なところで使われていたりとか
どんなとこで?
246 :
名無しさん@お腹いっぱい。 :2007/08/28(火) 06:28:38
「MACは基礎がセキュアだから絶対ウィルス感染しない」 を思い出した。
247 :
名無しさん@お腹いっぱい。 :2007/12/19(水) 02:20:02
知らぬ間にVxVM/VxFSが無料になってるとは・・・
まじかよ
* * * + うそです n ∧_∧ n + (ヨ(* ´∀`)E) Y Y *
250 :
名無しさん@お腹いっぱい。 :2007/12/21(金) 03:08:48
機能限定版だけどずいぶん前に無償化されてる。
251 :
名無しさん@お腹いっぱい。 :2008/02/10(日) 15:49:12
いらね。ZFSで十分
252 :
名無しさん@お腹いっぱい。 :2008/06/01(日) 18:12:10
>>222-224 とかの書き込みを見ると、
HDDの write cache は最近のOSなら有効にしても問題ないってことでいいですか?
253 :
名無しさん@お腹いっぱい。 :2008/09/06(土) 21:20:13
あげ
http://qb5.2ch.net/test/read.cgi/sakud/1112242102/118 118 : 削除彩虹 ★ : 2005/06/25(土) 21:09:51 ID:???0
本来、dat落ちするはずのスレを無意味な一行レス、空白行、AAなどで
存続させる意味はありません。
何のために即死判定や倉庫落ち判定の制限があるのか考えて下さい。
また、既に話題が尽きて有用な投稿がなく、保守のみで長期間延命されているスレは
需要がない、続ける意味がない、無用であると、2ちゃんねるの管理人は考えています。
議論するのは自由ですが、管理人の意に反するルールが適用されることはない
ということだけは言っておきたいと思います。
googleのGFSで十分
googleはあてにならない
最近DragonFlyのHAMMERとかNetBSDのWAPBLとか出てきてるみたいだけど実際どうなの? FreeBSDのgjournalは事実上async運用が前提みたいだし。
HAMMERは前評判はいいけど、DragonFly自体の評判がいまいちだからなぁ
ZFSはメモリ長者な64bit環境でないと厳しいらしいけど、HAMMERはi386のデスクトップ環境で 実用的に使えるレベルで収まるんだろうか? 大地タソのところでFreeBSDにHAMMERを移植するって話にZFSの品質改善が先じゃね?って意見が 出てるとか書いてあったけど、HAMMERなら少メモリで実用になるならそっちを進めてくれた方が 嬉しいよな。 Vista効果でいまどきNoteでも1〜2GBメモリ+160〜320GBのHDDってのも当たり前 になりつつあるから、FLASHやAdobeReaderの関係でのi386縛りを考えると、その状態でGNOME環境や KDE環境が余裕でオンメモリ稼働するならメリットはあるし。
260 :
名無しさん@お腹いっぱい。 :2008/10/20(月) 02:19:05
age
261 :
船木康博 :2008/10/20(月) 06:54:08
262 :
船木康博 :2008/10/20(月) 07:31:23
263 :
船木康博 :2008/10/20(月) 07:36:02
264 :
名無しさん@お腹いっぱい。 :2009/01/05(月) 14:06:30
ぬるぽ
ぬるぽするFSはいやだな
>>265 "life with UNIX"にでてきたな。
267 :
名無しさん@お腹いっぱい。 :2009/04/17(金) 08:36:29
268 :
名無しさん@お腹いっぱい。 :2009/05/12(火) 21:38:52
Linux板でzfsやbtrfsは酸っぱい葡萄じゃね?
逮捕されたなんとかさんは今どうなってんの?
Reiserさんね
>>267 の人、あまりに短期間で故障していることは何とも思わないのかな
FreeBSDの場合zfsなんてハイリスクなものより
gjournalが使えるのかsoftupdateのがましなのか
その情報がもっと欲しい
>>273 ZFSがハイリスクなんて、いつの話だ?
俺のところじゃ、メインマシンにZFSを導入してから
もう一年半くらい経つが、最初ちょっと苦労しただけで
後はノートラブルだぞ。
/からZFS化してるが快適そのもの。
>>273 いまさらsoftupdate云々言っているし、素人向けのFreeNASでもZFSを
普通に使っている現状を知らないし、お前いったい何年前の人間だ?
SATA HDD数台の個人サーバーと、GB/s近くでる箱を何台も繋げて使うエンタープライズでは、 リスクの評価が全く違うんだから、話が通じなくて当たり前。
いまさらsofutupdateなんて話をしている時点で、エンタープライズ云々なんて 無関係ってことすら理解できないお馬鹿さん乙
278 :
名無しさん@お腹いっぱい。 :2009/05/27(水) 19:39:06
煽る時ぐらいちゃんと綴り確認しろよ。効果半減だろ。
>>274 電源入れて眺めているだけだろ。
だいたいZFSはジャーナリングじゃないわけだけど
ディスクレスで済む容量のメモリ必須のZFSで
導入後はそりゃ快適かもしれないけれどずっとうるさそうだし
カリカリディスク削ってしょっちゅう障害に悩まされるのが関の山
次スレを建てるときは、ZFSやHAMMERを含ませるために、 【ZFS】UNIXファイルシステムスレ 2【HAMMER】 ってタイトルの方がいいかもね。 ただこの勢いだと、そのスレが埋まるのは数十年後・・・。
× そのスレが埋まる ○ このスレが埋まる
え?
285 :
名無しさん@お腹いっぱい。 :2010/04/11(日) 12:00:19
ume
286 :
名無しさん@お腹いっぱい。 :2010/04/29(木) 21:08:24
287 :
名無しさん@お腹いっぱい。 :2010/08/26(木) 19:41:58
こっちのスレははLinux以外のOSのファイルシステムということで
たまには age てみる ZFS って triple parity (raidz3)なんてのがあったんですね… さすがにこのレベルは実装としては珍しいのかな? (ジャーナリング関係じゃないけどさ)
どうなってんの
zfsで作ったRAIDZ1 poolに障害がでてFAULTED状態になってしまいました。
未バックアップの旅行写真と思い出のエロ動画が入っており何とか復旧させたいのですが、よろしくご教示頂けないでしょうか。
# zpool status
pool: zp-sturgeon
state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Destroy and re-create the pool from a backup source.
see:
http://www.sun.com/msg/ZFS-8000-72 scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zp-sturgeon FAULTED 0 0 1 corrupted data
raidz1 ONLINE 0 0 6
ad1 ONLINE 0 0 1
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 1
ad10 ONLINE 0 0 0
いろいろググったらとりあえずzpool clearでカウンターを消せとあったのですが、
# zpool clear zp-sturgeon ad1
internal error: 不正なバイト列です
Abort (core dumped)
setenv LC_ALL C すると
# zpool clear zp-sturgeon ad1
internal error: Illegal byte sequence
Abort (core dumped)
# zpool scrub zp-sturgeon
cannot scrub 'zp-sturgeon': pool is currently unavailable
と言われ何も出来ない状態。
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-09/msg00554.html > 1) Rename the zpool.cache to something else to be safe
> 2) Reboot, make sure that /boot/zfs points to the right location, and reimport the pools.
> 3) Should be fine from there on.
を参考に、/boot/zfs/zpool.cache をリネームして再起動、zpool importしてみました。が、
# zpool import
pool: zp-sturgeon
id: 1309405235458361560
state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
The pool may be active on another system, but can be imported using
the '-f' flag.
see:
http://www.sun.com/msg/ZFS-8000-72 config:
zp-sturgeon FAULTED corrupted data
raidz1 ONLINE
ad1 ONLINE
ad4 ONLINE
ad6 ONLINE
ad8 ONLINE
ad10 ONLINE
# zpool import zp-sturgeon
internal error: Illegal byte sequence
Abort (core dumped)
-fつけても同じでした。
ここで何かするんでしょうか?
zpool.cacheを元に戻して再起動し zpool statusするとad1とad8のCKSUMが0になりましたが、
それ以外何も変わらずです。
障害の心当たりとしては一週間前にmuninと一緒に入れたsmartmontoolsかなと。速攻deinstallしました・・・
dmesgeにはHDDぽいエラーは見受けられませんでした。
自分トコでは、HDDケーブルを交換したらエラーが出なくなったことがあった
復活したああああああああ 英語のフォーラムでzfsをアップデートしてみろみたいなやりとりがあったのを思い出し、 (そのやりとりではその後どうなったかは語られていなかった・・・) ダメ元でFreeBSD 8 stableのZFSがver15だったのを、 9current ver28にしたらzpool import -F が通りました! 実際は新たにUSBメモリに8stable入れて、9currentをcvsup build/installworld 片手間で1週間かけてしまったのでこれで直らなかったらと思うと・・・ # zpool import -f zp-sturgeon cannot import 'zp-sturgeon': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Mon Jun 6 21:43:44 2011 should correct the problem. Approximately 30 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F zp-sturgeon'. A scrub of the pool is strongly recommended after recovery. # zpool import -F zp-sturgeon Pool zp-sturgeon returned to its state as of Mon Jun 6 21:43:44 2011. Discarded approximately 30 seconds of transactions. 修復してやるが最後の30秒間の記憶と引き替えだとの事でした。 たぶん大したことないデータのはずなので躊躇することなくimport。 >293 全ドライブの抜き差しまでは一度試してみました。 HP Proliant Microserverなので、ad4-10(0-3番)はエンクロージャーで交換不可なのですが、ad1だけは光学ドライブ用の空きコネクタに繋いでいたので、9currentがダメだったときはad1のケーブル交換を考えていました。
28で復旧後、15でマウントできるのかは未確認です。 仕事から帰ったら試してみます。
>>295 マウント出来るようになって良かったですね
家の8.2-STABLEでは、zpoolのバージョンが28になってるから
15でマウント出来なかった時に、currentを使うのがためらわれる場合は、
8.2-STABLE使うと良いかも
余程メモリかつかつでない限りは FreeBSD では 今後は ZFS がメインなのかな
全くそんな気はしない。
300 :
名無しさん@お腹いっぱい。 :2011/11/04(金) 00:03:09.12
ジャーナリングとは関係ないけど、 Write at Onceなファイルシステムってある?
ファイルを上書きできるから、LFSは違うような?
write at once というのがよくわからない
write onceと書きたかったんでそ、おそらく
普通はそういうメディアを仮想化して、物理レイヤでは追記しかできないのを、 論理的には書き換え(上書き)とか削除に見せかける、ってことをするんだけど、 追記しかできない、ってのもあるんだな。 てかat onceだと、一回の書き込みで全部書き込む、ということしかできない って意味になっちゃうような。
セッション作らないでCD-R一気書きして閉じる場合なんかに使われてたね
| | ガガガッ
| |
人
∧_∧ < >_∧∩
( ・∀・) 人`Д´)/ ←
>>170 と ) < >_∧∩
Y /ノ .人`Д´)/ ←
>>264 / ) < >_∧∩
_/し' //. V`Д´)/ ←
>>265 (_フ彡 /
ジャーナリングファイルシステム
311 :
名無しさん@お腹いっぱい。 :2013/09/10(火) 21:41:29.17
古いな
ジャーナリングファイルシステム
ジャーナリングファイルシステム
ジャーナリングファイルシステム
315 :
名無しさん@お腹いっぱい。 :2014/01/11(土) 16:46:04.29
ジャーナリング目が悪いシステム
316 :
名無しさん@お腹いっぱい。 :2014/02/06(木) 05:17:29.15
ぼくジャーナリスト。
317 :
名無しさん@お腹いっぱい。 :2014/04/15(火) 00:09:04.54
いいかも
ぬるぽ
319 :
. :2014/05/03(土) 16:23:24.10
ガッ
320 :
名無しさん@お腹いっぱい。 :2014/05/05(月) 02:36:34.25
ぬるぽ
おっぱい
| | ガガガッ
| |
人
∧_∧ < >_∧∩
( ・∀・) 人`Д´)/ ←
>>318 と ) < >_∧∩
Y /ノ 人`Д´)/ ←
>>320 / ) < >_∧∩
_/し' //
(_フ彡
ジャーナリングファイルシステム
324 :
名無しさん@お腹いっぱい。 :2014/08/05(火) 21:54:59.46
ext4
ぬるぽ
Ext4
S.I.P.
ext4
ジャーナリングではないファイルシステム
ジャーナリストのファイルシステム
ぬるぽ
ジャーナリングファイルシステム
ジャーマンポテトファイルシステム
ジャーナリングファイルシステム
ファイルシステム
ジャーナリング
ファイル
フォルダ
ジャー
Btrfs
NTFS
どうも
ext4
ジャーなりんぐ
ReiserFS
あけおめ
ことよろ
ext4
ext5
ZFS