[過去ﾛｸﾞ] /**ファイルシステム総合スレ その7**/ (955ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
57(4): 45 2007/03/14(水)00:37 ID:y4c2ZpRt(1/3) AAS
>>45 自己レスです。
外部ﾘﾝｸ[php]:homes.cerias.purdue.edu
を見たところ、確かにファイル名のハッシュ値を使っているようですが
2.6.20.2のfs/reiserfs/namei.c:1575
を見るに少なくとも指定ディレクトリ(エントリ)の指定ファイル名の
ファイルを探すときはこの値を探索した後線形探索するように
読めました(無論細部は追ってないし動かしてもいない)。
で、コリジョン＝エラーではないと思う。それだけ。
60(1): 2007/03/14(水)21:46 ID:/NerAE7J(1/3) AAS
>>57
コリジョンが起こったファイル名で書き込みに行った場合、
衝突されたファイルを上書きしてしまうと思うが？
これを避けようとすると、毎回コリジョンの有無を調べなければならず、
ハッシュの優位性はなくなってしまわないか？
61: 2007/03/14(水)22:04 ID:/NerAE7J(2/3) AAS
>>57
レスがかみ合ってなくてスマソ。
ハッシュで探索後に、線形探索。
これではハッシュの意味が無い上にもの凄く遅くない？
62(1): 2007/03/14(水)22:16 ID:/NerAE7J(3/3) AAS
>>57
連投スマソ。
これは俺の無知だね．．．
>57はコリジョンが起こった際の処理方法についてカキコしてたわけだ。
申し訳ない。
だとすると>35の意見は果たしてどうなんだろうか？
63(3): 57 2007/03/14(水)23:53 ID:y4c2ZpRt(3/3) AAS
ハッシュを使っているのは文字列の代わりに固定サイズの短い数字を使った方が
B木のキー(の一部)として優秀なだけだと思います。ただハッシュなので、B木を
降りていった後にハッシュの元の文字列かどうかは確認する必要があり、B木の
キーで同じ値になっている部分を走査したり探索したりする必要があるのかなぁ
と思いました。
元の文字列に対してハッシュ値が現実的に十分1:1になっている(一意になって
いる)なら最後に走査したり探索したりする必要はないんだけど、B木まで使う
(レコード数が大きいことを想定している)ファイルシステム(手堅い印象)で
ハッシュが重ならないことを前提にしたりするの？と疑問が残ったので、資料と
ソースを探してみました。で、>>57 というわけ。
省9
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s