[過去ﾛｸﾞ] /**ファイルシステム総合スレ その7**/ (955ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
208(1): 2007/04/08(日)22:44 ID:tkpoMrl5(1/3) AAS
>>205
なんかオレが調べた結果と違うなあ。(ただしFreeBSD上)
手元のPCはディレクトリとか込みで200万ぐらいファイルがあるんだけど、
zgrepで調べたほうが遅くなる。
アルゴリズム的にファイル数が増えるにしたがって差が開くはず。
locateのデータベースはファイルリストをソートし、一つ前のファイルパスと
異なる部分からしか記録してないのでファイルサイズが小さい。
しかも、検索する際にスキャンするデータの大きさはlocatedbのサイズ分だけ
ですむ。
gzipしたファイルを検索する場合は元のファイルの大きさ分スキャンしないと
省10
209(2): 2007/04/08(日)23:31 ID:HNNwKpZg(2/2) AAS
みんなそんなにファイル調べる事あるの？
>>189
コマンドインストールしてるかなら、パッケージ管理用のコマンド使うし
自分がパスを通している所以外にコマンドが入っていることなんてまず無いし・・・
で、動的なファイル検索ならfindを使う。
色々調べ方を指定できるfindの方が便利だし。
つまり、偶にしか使わない機能だから、ちょっと位速くなっても・・・という気分。
210: 2007/04/08(日)23:39 ID:S1gIGviP(3/3) AAS
>>209
一般ユーザで find / するとパーミッションで読めないファイルあるでしょ。
(これはlocateも同じ問題が発生するが)
わざわざ毎回 find / することを防ぐために locatedb 作ってるんだからさ。
locatedb 更新後に追加したら、updatedb 実行すればいいだけだし。
211(1): 2007/04/08(日)23:43 ID:zsJ2r/Ru(2/2) AAS
>>208
こっちはLinux。規模はやっぱり200万ちょっとくらい。
updatedbのデータはもう作らなくなってしまったので今追試は
できないけど、データ構造的にはupdatedbの方が高速になるはずと
いうのは同意。でも、結果はそうでなかったので「？」だった。
「.」で探して全スキャンとかしてみるとどう？
>>209
大抵のファイルのありかは頭に入っているわけなので、
調べる必要がある時は「わからーん」という状況のことが多い。
そういう時にfindではターンアラウンド大きすぎて試行錯誤できず
省3
212(1): 2007/04/08(日)23:52 ID:tkpoMrl5(2/3) AAS
ソースとか溜め込んでるとlocateは便利だよ。
例えば前にコンパイルしたバージョンほげほげのtarballはどこいったって感じで。
あとconfigureでライブラリとかヘッダーファイルがないって言われたときも結構使うね。
Perlのモジュール使ってるときにも元の.pmファイルが見たいときがあるんで使うなあ。
なんとなくだけど、自分でコンパイルしない人はlocate使わないのかも。
213: 2007/04/08(日)23:58 ID:FgPsXoOH(1) AAS
>>212
findだと大変だもんね。
214(2): 2007/04/08(日)23:59 ID:+N5qr5Yv(3/3) AAS
自分でコンパイルするときはどこに何が置かれるのかおよそ把握するし。
ログを残しておけば、それを見ることも出来るし。
コンパイル専用ユーザとか作るのも普通でしょ？
215: 2007/04/09(月)00:04 ID:tkpoMrl5(3/3) AAS
>>211
% time locate / > /dev/null
1.058u 0.014s 0:01.07 99.0% 16+227k 0+0io 0pf+0w
% time zgrep / filelist.sort.gz > /dev/null
2.449u 0.067s 0:02.57 97.2% 97+388k 0+0io 0pf+0w
やっぱzgrepのほうが遅いみたい。
% time zfgrep / filelist.sort.gz > /dev/null
8.372u 0.044s 0:08.45 99.5% 96+379k 0+0io 0pf+0w
% time zegrep / filelist.sort.gz > /dev/null
2.485u 0.029s 0:02.52 99.2% 96+387k 0+0io 0pf+0w
省2
216: 2007/04/09(月)00:05 ID:atKY9uJN(1/4) AAS
>>214
小規模かつ一人でやってんならそうでしょうね。
217: 2007/04/09(月)00:06 ID:vrz2OUFg(1) AAS
>>214
tarball内のファイル名全部を記憶してるわけ？
log取ったあとに移したりすると意味無いから、
ログより新しい情報で無いと使えないことがある。
218(1): 2007/04/09(月)00:12 ID:YK4Cy17y(1) AAS
locateは使った時に便利さが実感できるけど
使わない時は本当に使わないね。
半年くらい前にサウンドデバイスのテストしようとして
locate "*wav" したのが最後だ。
cronで毎日更新してるけどなんかもったいないな。
219: 2007/04/09(月)00:15 ID:atKY9uJN(2/4) AAS
>>218
まぁ、いいんじゃない？
220: 2007/04/09(月)00:17 ID:PFZ7GF/k(1/2) AAS
あー、locateバリバリ使わないとどうにもならなかった事例思い出した。
前任者が勝手コンパイルで入れたsenmdmailの入れ替え。
インストールログが一切なくて、そこらじゅうのマシンのいろんなディレクトリに展開されてる
sendmailの内、どれを使ってコンパイルしたのか分からない。
仕方ないからマシン全てでlocateを実行しましたよ。
findだと日が暮れてたと思う。
結局、コンパイルに使ったソースファイルはどこにもなかったけど。
221(1): 2007/04/09(月)00:19 ID:YC9/TDq9(1) AAS
locate 使うかどうかなんて議論するほどのことか?
便利だと思うなら使えばいいし、
必要ないと思うなら使わなきゃいい。
どうしてもやりたいなら雑談スレでやってくれ。
222: 2007/04/09(月)00:23 ID:atKY9uJN(3/4) AAS
>>221
うっせぇよ。どんだけ偉いんだお前？
223(1): 2007/04/09(月)00:41 ID:SYt9P2O4(1) AAS
自分で管理もしてないPCの locate の結果が信用できるのかね。
しかもそんな状態の。
224: 2007/04/09(月)00:45 ID:atKY9uJN(4/4) AAS
>>223
＞自分で管理もしてないPCの locate の結果が信用できるのかね。
言い出したら1日前のファイルリストなんぞなんの信頼性もない。
その正当性は人が確認すればいい話。
何もlocate hoge | xargs rm -rfなんてことがしたいわけじゃないし。
ファイルが今もその辺にあることを「知りたい」だけなんだよ。
225: 2007/04/09(月)00:54 ID:PFZ7GF/k(2/2) AAS
locateの機能をファイルシステム側で提供してくれるとうれしいと思わないかい？
rlocateのやり方だとリモートディスクが変更された場合に検索できなくなるから、
ファイルシステムの機能として取り込んでくれないかなあ。
ぶっちゃけ頓挫したWinFSみたいにDBにメタデータつっこんでくれれば、
なんでもし放題でいいんだけどなあ。
226: 2007/04/09(月)00:56 ID:b08awD+c(1) AAS
beagleとか大して使われなかったな
227: 2007/04/09(月)02:22 ID:EXUr/7hN(1) AAS
単純圧縮だと時間が線形に増えるのに対し、
木検索だとlog2になるので、数が増えれるほど差が開く。
線形検索だと処理が単純な分オーバーヘッドが少ないので、
数が少ない場合は線形の方が速いし、数が多くなれば木の方が速くなるだろ。
更に、パイプでつなげて複数のプロセッサを同時に使えるケースだと単純2倍になるとか、
条件変数をいじれば閾値が変わる。
比較するなら条件付けないと意味なさげ
上下前次1-新書関写板覧索設栞歴
あと 728 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s