[過去ﾛｸﾞ] /**ファイルシステム総合スレ その7**/ (955ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
35(3): 2007/03/12(月)21:54 ID:Y3icS7v7(3/6) AAS
>これってどういうことなんだろう？
ファイル名のハッシュ使っているr5は、実質1000万ほどで
コリジョンが発生するので、これ以上はファイルは作れないということ。
37: 2007/03/12(月)22:06 ID:V9lwlMzJ(2/4) AAS
>>35
> ファイル名のハッシュ使っているr5は、実質1000万ほどで
> コリジョンが発生するので、これ以上はファイルは作れないということ。
当然確認とってるんだよな？
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.037s