[過去ﾛｸﾞ] /**ファイルシステム総合スレ その7**/ (955ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
187(1): 2007/04/07(土)21:37 ID:qEROFzP6(1) AAS
ファイルシステムってハマる時はハマるのだな…。
自分ならとても解決できなかったように思う。
locateは入っていたがprelinkは入れてなかったので入れようかと思っていたが、
こんな理解不能の事態が発生するのでは、いれていいかどうか不安に感じてしまう…。
188(1): 2007/04/08(日)00:43 ID:HNNwKpZg(1/2) AAS
>>186
だって全然使わない、デスクトップ検索自体しないし・・・
GoogleDesktop入れて気付いたが
広大なwebならともかく自分の管理してる所なんだから
情報はちゃんと整理してる、というかしていないときもちわるい
Spotlightも使わない
なのでlocateのありがたみもよく解らんです
189(1): 2007/04/08(日)00:50 ID:S1gIGviP(1/3) AAS
>>188
/home以下じゃなくて、使ったこと無いコマンドとかインストールされているか
調べるために、 locate hoge とか実行する。
というか、「お前は自分の管理してるマシンのファイル名を全部覚えているのか？」
もしやっているならご苦労なことだ。
190(1): 2007/04/08(日)01:46 ID:+N5qr5Yv(1/3) AAS
コマンドなら、whichでいいだろ。
locateなんてわざわざ使わん。
191: 2007/04/08(日)01:49 ID:S1gIGviP(2/3) AAS
>>190
パス通してない無い場合は？
コマンドは例だったが適用例は設定ファイルとかファイル全般。
192: 2007/04/08(日)01:54 ID:AO6opwfy(1) AAS
俺はwhichもlocateも使うよ。
locateはかなり良く使うけどなぁ。
193(1): 2007/04/08(日)02:34 ID:Hzw/JAkU(1) AAS
cronでslocate走った後って、メモリ消費量増えない？
194(2): 81 2007/04/08(日)04:25 ID:HBM8UdKZ(1/2) AAS
>>187
いや、自分の場合はrootをr/oにするというハックをしている状況なのでハマっただけです。
組み込み系のアプライアンスのための要求なので普通のホストシステムならたぶん問題はないでしょう。
しかし今回の経験で学んだのは、Linuxホストのrootをr/oにするっていうノウハウがあまり
確立されてないという事。漠然とセキュリティーのためにそうする事もあるという事を
見聞きしてましたが、今回のことも含め、ハマる穴は沢山ありそうです。
195: 2007/04/08(日)04:34 ID:IVjfIv3g(1/2) AAS
>>194
BSDに比べて/をroにすることを考えていないといえば考えて無いとはいえると思う。
prelinkとかは止めりゃいいだけだが、
/usr のパーティション分けたら動かないものとかあったりするし。
196(1): 2007/04/08(日)05:55 ID:VhLkTwV9(1) AAS
というか、cronでprelinkなんか動かしているその組込み系の
ディストリを明記してくれた方が有益だと思う。
あるいは、PC向けのディストリをベースに自力で構築している
ならそう書くべきだな。
197: 2007/04/08(日)09:31 ID:M3c2/sEX(1) AAS
>>193
> cronでslocate走った後って、メモリ消費量増えない？
ファイルキャッシュが増えるからだよ。
198: 81 2007/04/08(日)12:57 ID:HBM8UdKZ(2/2) AAS
>>196
失礼しました。 単にCentOSをアプライアンスとしてカスタムインストールしているだけです。
「組み込み」とはいっても中身はPCマザボの普通のサーバーですので。 面白いのは色々とごちょごちょ
いじっている時に/etc/rc.d/rc.sysinitにこんなコードを見つけた事：
if [ -f /etc/sysconfig/readonly-root ]; then
. /etc/sysconfig/readonly-root
if [ "$READONLY" = "yes" ]; then
# Call rc.readonly to set up magic stuff needed for readonly root
. /etc/rc.readonly
fi
省3
199: 2007/04/08(日)13:04 ID:v21r+S80(1) AAS
>>194
ひとりでこつこつとやっててもむずかしいよ。
組込み系は組込み系のコミュニティーで
ノウハウが貯ってるからねぇ。
200(1): 2007/04/08(日)14:22 ID:Q1EoOsla(1) AAS
システム全体に全文検索のindexを作るのは現実的じゃないからファイル名検索は現役だけど、
slocateはupdatedbを実行するまでindexが更新されないのが困る。updatedbの実行中は負荷高いし
モジュールの追加に抵抗が無ければ、ディレクトリツリーを変更するシステムコールをフックして、
インデックスを即時変更するrlocateの方がスマート
201(1): 2007/04/08(日)14:56 ID:+N5qr5Yv(2/3) AAS
updatedb重いよなぁ。
デュアルコアとかマルチプロセッサなら多少は軽減されるだろうか？
ま、どっちにしてもサーバ向けの機能ではないし、いらないっちゃいらない。
202: 2007/04/08(日)15:25 ID:ZmJtdjLW(1) AAS
重いと感じない私は使い方間違ってる？
動作中は確かにディスクアクセスが増えるけど、CPUそんなに使わないし
五分もしないうちに終わるし。
ディスク合計1テラ弱を八割程度しか使ってないから？
ｼｽﾃﾑはP4HT2.8G SATAディスク500GB+400GBです
203: 2007/04/08(日)18:21 ID:kS1N8DBw(1) AAS
updatedb って中身は主として find を呼び出している
シェルスクリプトとして実装されていることが多いですよね。
nice したらそんなに邪魔にならないし、
そんなに邪険にしてやらなくてもいいんじゃないだろうか。
204: 2007/04/08(日)21:30 ID:IVjfIv3g(2/2) AAS
>>201
サーバとデスクトップで区別する理由が分からん。
どっちでも有用だろ。
手動実行しても重たいとは思わないが、
普通はcronでniceつきで回すだろうから全く問題ない。
>>200
rlocateって標準装備してるdist.ってある?
205(1): 2007/04/08(日)21:50 ID:zsJ2r/Ru(1/2) AAS
ちょっと前にさ、locateが速いのはホントにupdatedbのおかげなのか？と思って
・普通にupdatedb + locate
・単なるfind | gzip > list.gz + zgrep
で比較してみた。
そしたら、なんとfind + zgrepの方が、というかlocateよりも
zgrepでリストファイル検索した方が速かった。リスト作るのも
当然findのみの方が速い。updatedbは内部でデータベース作ってる
わけだけど、スペース削減の意味がほとんどない今、もう過去の
遺物かも知れんと思ったよ。
206: 2007/04/08(日)22:05 ID:EmYGF54Z(1) AAS
過去の遺物だろうね。
fedoraではFC3あたりからlocateのサービスが切られてるよ。
それ以前はデフォルトでcronで走るようになってたけど。
上下前次1-新書関写板覧索設栞歴
あと 749 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s