/**ファイルシステム総合スレその7**/

[過去ﾛｸﾞ] /**ファイルシステム総合スレその7**/ (955ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

144(1): 2007/03/29(木)12:56 ID:XgJoJt9J(2/2) AAS
ｱﾘﾏｼﾀ
外部ﾘﾝｸ:www.sophia-it.com

でも意味がわかりません。

145: 2007/03/29(木)14:14 ID:H9I3kno8(1) AAS
>>144
外部ﾘﾝｸ:www.google.co.jp

146: 2007/03/29(木)21:55 ID:r+t2Jggl(2/2) AAS
㌧
つまりﾌｧｲﾙが断片化しないよう、余分に場所を確保しとくっていうﾗｲｻﾞｰ4の真似をした仕組みだね。

ところで将来のﾌｧｲﾙｻｲｽﾞなんて予測できないと思うのだけど、
ｴｸｽﾃﾝﾄの大きさはどうやって決めるのだろう？
むかしｸﾗｽﾀと呼んでいたものとは違うの？

147(1): 2007/03/29(木)22:47 ID:EvQbMu8q(1) AAS
エクステントって昔からエクステントと呼んでいたような。
VxFS とか。

148: 2007/03/29(木)23:07 ID:R0MPJnFu(1) AAS
>>147
XFSのオンラインデフラグがext4についてくれれば、とりあえず最強なんだがな。
年に数回はデフラグしたい。

149(2): 2007/03/30(金)09:25 ID:8SUX2/zw(1/2) AAS
MSDOSは複数のセクターをまとめた｢クラスタ｣という連続領域単位でファイルを管理してた。
インデックスを少なく押さえることと、断片化を少なくするのが目的。
低速媒体のフロッピーが主体だったため、断片化を避けるのは非常に重要だったせいもあるが
当時の大型機からの借用だったと理解してる。
エクステントの説明をみると同じものにみえるのだけど、何かちがうのだろうか？

150: 2007/03/30(金)11:23 ID:TnuWXj4a(1) AAS
>>149
クラスタサイズが可変なんじゃね？

151: 2007/03/30(金)12:54 ID:8SUX2/zw(2/2) AAS
それをどうやって決めてるかが肝

152: 2007/03/30(金)14:53 ID:1nTHIbAF(1) AAS
エクステントサイズが固定の方が断片化は起こり肉印とちゃう？

153: 2007/03/31(土)00:34 ID:MhCzl/tA(1) AAS
>>149
ブロック管理だと
ファイルが巨大になると
インデックスを引くのに時間がかかるようになるが
エクステント管理だとうまく連続ブロックに配置できれば時間が節約できる。

154: 2007/03/31(土)01:12 ID:ifE6Hzsr(1) AAS
インデックスってエクステント単位で振られるんじゃないの？

ブロック＝IO最小単位
エクステント＝領域割当最小単位
っていう理解で基本的にはいいんだよね？

155(1): 2007/03/31(土)02:18 ID:cMH9eCiA(1) AAS
違う。

エクステントってのは連続したブロックのこと。

あるファイルが1～10、15～20のブロックからなっている時、ブロックベースの
ファイルシステムでは (1 2 3 4 5 6 7 8 9 10 15 16 17 18 19 20) という
インデックスで表現するのに対し、エクステントベースのファイルシステムでは
((1 10) (15 5)) のように表現する。

156: 2007/03/31(土)07:52 ID:Ud+o/4Fl(1) AAS
>>155
inodeが圧縮できる？よくわかってませんが。

157(1): 2007/04/01(日)08:47 ID:jgewp6D4(1) AAS
で、最初の疑問ですが、
断片化が起こるのは、ファイル更新時のサイズ変化が要因だとすれば、
あらかじめ変化量を予測してエクステントを確保する必要があるわけだけど
どうやるのですか？

158(1): 2007/04/01(日)09:20 ID:Miicym17(1) AAS
extentの仕組みについて人に聞く前にまずググってみました。

ズバリというページがありません！

外部ﾘﾝｸ[html]:www.spa.is.uec.ac.jp
外部ﾘﾝｸ[html]:www.kyoto-sr.co.jp
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
外部ﾘﾝｸ[htm]:www.simosimo.info

いったいエクステントについてよく理解するためにはどうしたらいいのか！
参考書とか専門書とか買わないとわからんかな。

159: 2007/04/01(日)11:10 ID:5ZbsiFAt(1) AAS
>>158
くっつく？ひっつけばチャクラエクステントが発動します。

160: 2007/04/01(日)18:24 ID:AzuElS/P(1) AAS
>>157
ジャーナルから commit するまで割り当てを遅延する
ディスクの空き容量が少なくなるまでファイルを密に配置しない
その他色々

161: 2007/04/02(月)09:07 ID:NH19NaTw(1) AAS
ありがとうございます！
しかしジャーナルに書き込むのは更新時が主ですよね？
とすれば、新規作成時に将来サイズの予測ができることがエクステントの考え方としては最重要という気がします。
ファイルを密に配置しないという方針は有効ですが、エクステントとは別の考え方ではないでしょうか？

162: 2007/04/04(水)09:53 ID:NWetzSkB(1) AAS
自己レスです。
エクステントの大きさは使用者が決めるようです。
しかも初期と伸張分をべつの大きさにする方法もあるようです。
したがって、設計段階でのサイズ予測はいらないということのようです。

163(2): 2007/04/05(木)11:44 ID:6CwC0rrT(1/2) AAS
XSFフォーマットのディスクに入れたファイルとかを
NTFSフォーマットのWINDOWSへコピーした場合普通に開けるのですか？

164: 2007/04/05(木)13:15 ID:OdzCRDEa(1) AAS
>>163
なぜ、自分で試さない？

165: 163 2007/04/05(木)13:24 ID:6CwC0rrT(2/2) AAS
パソコンすら持ってないんです
うぅ・・

166: 2007/04/05(木)13:30 ID:UHEFuWv5(1) AAS
そんな人が聞いてどうすんだろ。

167: 名無しさん＠お腹いっぱい 2007/04/05(木)15:20 ID:BtA25953(1) AAS
流行りのエアギターならぬエアLinuxってやつだな。

168: 2007/04/05(木)16:26 ID:xu52r8kl(1) AAS
俺の若い頃は藁半紙に書いたキーボードとライオン本でカーネルハックの練習をしたもんだよ

169: 2007/04/05(木)17:40 ID:ArTajbou(1) AAS
エアオナニー

170: 2007/04/05(木)23:16 ID:jNYQCAbT(1) AAS
牛乳石鹸をマウスに見立てて、X Windowへの思いをはせたもんだ

171: 81 2007/04/06(金)04:19 ID:kERYUymx(1/9) AAS
mount -o mount,ro / がbusy で帰ってきて困ってた81(80と間違えてた)です。

２週間ほどたってやっと再現されました。　しかもラッキーに2台。追加したprintk
から以下のような出力。　

fs_may_remount_ro found pending delete: 0xe6feac80
do_remount_sb: failed fs_may_remount_ro: -138124224
do_mount: failed do_remount: -16

大切なのは最初の１行で以下のprintkから出力されました。

　fs/file_table.c:
　int fs_may_remount_ro(struct super_block *sb)
　{
省10

172: 81 2007/04/06(金)04:29 ID:kERYUymx(2/9) AAS
さて、まずどのファイルか？　gdbを/proc/kcoreに繋いで除きました。

(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_iname
$12 = "libz.so.1.2.1.2", '¥0' <repeats 20 times>
gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_iname
$14 = "lib¥000t", '¥0' <repeats 30 times>
(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_parent->d_iname
$16 = "usr¥000]", '¥0' <repeats 30 times>
(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_parent->d_parent->d_iname
$18 = "/¥000dline", '¥0' <repeats 28 times>

というわけで問題のファイルは"/usr/lib/libz.so.1.2.1.2"
省2

173: 81 2007/04/06(金)04:41 ID:kERYUymx(3/9) AAS
もうちょっと掘り下げる。

(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_inode.i_ino
$24 = 230991

iノード番号は230991。

# ls -li /usr/lib/libz.so.1.2.1.2
231021 -rwxr-xr-x 1 root root 63624 Jul 21 2005 /usr/lib/libz.so.1.2.1.2

？？？　食い違うぞ？？？
省11

174: 81 2007/04/06(金)04:50 ID:kERYUymx(4/9) AAS
それでもってntpがどういうファイルを開いているか見ると、なんか怪しげな状態。

# lsof | grep ntp
ntpd 21393 ntp cwd DIR 3,3 4096 2 /
ntpd 21393 ntp rtd DIR 3,3 4096 2 /
ntpd 21393 ntp txt REG 3,3 431016 227728 /usr/sbin/ntpd
ntpd 21393 ntp mem REG 3,3 230494 /usr/lib/libkrb5.so.3.2 (path inode=231028)
ntpd 21393 ntp mem REG 3,3 194104 /lib/libdl-2.3.4.so (path inode=195480)
ntpd 21393 ntp mem REG 3,3 47468 194100 /lib/libnss_files-2.3.4.so
ntpd 21393 ntp mem REG 3,3 210587 /lib/tls/libc-2.3.4.so (path inode=210651)
ntpd 21393 ntp mem REG 3,3 194115 /lib/libcom_err.so.2.1 (path inode=195486)
省10

175: 81 2007/04/06(金)04:52 ID:kERYUymx(5/9) AAS
ちなみに正常（？）な状態のntpはこんな感じ。

proto5# lsof | grep ntp
ntpd 2101 ntp cwd DIR 3,2 4096 2 /
ntpd 2101 ntp rtd DIR 3,2 4096 2 /
ntpd 2101 ntp txt REG 3,2 431016 241991 /usr/sbin/ntpd
ntpd 2101 ntp mem REG 3,2 941024 260982 /lib/libcrypto.so.0.9.7a
ntpd 2101 ntp mem REG 3,2 11776 260970 /lib/libcap.so.1.10
ntpd 2101 ntp mem REG 3,2 1525004 177572 /lib/tls/libc-2.3.4.so
ntpd 2101 ntp mem REG 3,2 16800 294968 /lib/libdl-2.3.4.so
ntpd 2101 ntp mem REG 3,2 415188 247066 /usr/lib/libkrb5.so.3.2
省9

176: 81 2007/04/06(金)04:56 ID:kERYUymx(6/9) AAS
ちなみにこの症状は問題のおこった２つのシステムでまったく同じ。　
おなじlibz.soでひっかかり、やはりntpが同じような状態になってます。

さて、この"path inode"というのがキモのようですが、なんの事か
全然分からないからどこかで調べてきます。　

ここまでの情報で何か助言があればよろしくおねがいします。　

177: 81 2007/04/06(金)05:25 ID:kERYUymx(7/9) AAS
なお、問題のあるシステムでは問題のあるのはntpだけでありません。

# lsof | grep "path inode" | cut -d" " -f1 | sort | uniq
agetty
crond
ifplugd
klogd
mingetty
ntpd
portmap
syslogd
省4

178(1): 2007/04/06(金)05:46 ID:lKLkq3ZS(1/2) AAS
prelinkによってロード中の共有ライブラリが置き換えられているのかな？

prelinkを止めてみるとか。

179: 81 2007/04/06(金)06:12 ID:kERYUymx(8/9) AAS
>>178
そっ、それだ～～～～～～～～～～～～。

こんなもの見つけました。

/etc/cron.daily/prelink

一発で再現出来ました。

正常状態：
省14

180(1): 2007/04/06(金)06:56 ID:lKLkq3ZS(2/2) AAS
オープン中のファイルは移動したり削除しても影響を受けないから、prelink の
動作自体は乱暴でもないような。

lsof の出力に path inode が出ているのは、オープン中に置き換えられたファイルで
ある事を示しているのを初めて知ったから俺も勉強になったよ。

問題が解決して良かったね。

181: 81 2007/04/06(金)07:16 ID:kERYUymx(9/9) AAS
>>180
ありがとうございます。

> lsof の出力に path inode が出ているのは、オープン中に置き換えられたファイル
普通のファイルのように素直に"deleted"とか書いてくれればもっと早く解決したかもしれないんですけどね。
ちょっとその場合とは意味が違うのでしょう。　後で勉強したいと思います。

# cat > hoge.txt &
[1] 9317
# lsof | grep hoge.txt
cat 9317 root 1w REG 253,0 0 15 /hoge.txt
# rm hoge.txt
省2

182(1): 2007/04/07(土)00:19 ID:PW/Wm1N9(1) AAS
よくそこまで調べたなー

/proc/kcoreをgdbに繋ぐなんてテクニック初めて知った
すげぇわ

183: 2007/04/07(土)00:22 ID:l0bc2a+o(1) AAS
>>182
/proc/kcoreはgdbで使うための仮想ファイルだろ？

184: 2007/04/07(土)05:48 ID:07BPrRWv(1) AAS
外部ﾘﾝｸ[xml]:www.gentoo.org
4. 既知の問題と解決策

185(1): 2007/04/07(土)15:32 ID:w4EDI2Lw(1) AAS
怠け者な俺は、locateとかprelinkなんて余計なものは真っ先に外しちゃうからなぁ。

186(1): 2007/04/07(土)21:33 ID:Vx40DlGH(1) AAS
>>185
locateの便利さがわからんか。
デスクトップ検索の先駆けだぞ。

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で走るようになってたけど。

207: 2007/04/08(日)22:08 ID:dD+lSYL+(1) AAS
makewhatisも切ってほしい

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倍になるとか、
条件変数をいじれば閾値が変わる。

比較するなら条件付けないと意味なさげ

228: 2007/04/09(月)12:40 ID:jp1FtvCv(1/2) AAS
reiser,reiser騒ぐヤツはどこでも疎まがられてますな。
(Reiser4. BEST FILESYSTEM EVER.)

229: 2007/04/09(月)12:50 ID:F3Ij9AuO(1) AAS
彼らが亡き者にされないことを祈ります

230: 2007/04/09(月)13:34 ID:jp1FtvCv(2/2) AAS
>REISER4 FOR INCLUSION IN THE LINUX KERNEL.
危な臭くなってきますた。

231: 2007/04/09(月)13:53 ID:72H5EoZf(1) AAS
どこに書かれていますか

232: 2007/04/09(月)14:06 ID:2R5UgYQX(1) AAS
Reiserの事件が起きたのが不思議だったが
このスレの速度見てたら納得した。

Linuxに於いてファイルシステムは重要な位置にある。

Reiser裁判の続報マダー？

233: 2007/04/09(月)15:53 ID:jlcenkeg(1) AAS
SCO裁判と合流いたします。

234: ◆IIiDC8JS7w 2007/04/10(火)01:12 ID:7nQI0l/r(1) AAS
4/6からreiser4のお話でLKMLが荒れてます。
お話はベンチマークでreiser4最強説から始まる。。。

BEST FILESYSTEM EVER.
外部ﾘﾝｸ:marc.info
外部ﾘﾝｸ:marc.info

REISER4 FOR INCLUSION IN THE LINUX KERNEL.
外部ﾘﾝｸ:marc.info

Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE
外部ﾘﾝｸ:marc.info

235(1): 2007/04/10(火)09:09 ID:TLRAIA8b(1) AAS
mmカーネルには入ってるのだから、
メインストリームに入れられない理由が技術的問題なんてありえない。

236: 2007/04/10(火)17:24 ID:SKiObrIB(1/2) AAS
>>235
ここまで大きくなると、政治も技術なんだよね。

237: 2007/04/10(火)17:35 ID:NbCL9/FB(1) AAS
単にコミュニケーション能力だろ？

238(1): 2007/04/10(火)18:39 ID:72LWlPWO(1) AAS
メインストリームに入れたとして誰がメンテナになるの？
一緒に変更されるIO周りのメンテナンスは？
入れて終わり、じゃないから難しい

239(1): 2007/04/10(火)22:20 ID:WYQ/GLOl(1) AAS
>>238
俺だけど？

240: 2007/04/10(火)22:51 ID:SKiObrIB(2/2) AAS
>>239
お前じゃぁ、やっぱり見込み無いな・・・。

241: 2007/04/10(火)23:22 ID:epWNgzd4(1) AAS
akpmなら、akpmならやってくれる！！

242(1): 2007/04/10(火)23:45 ID:meYFnXcY(1) AAS
mm＝マジムカツク

243: 2007/04/11(水)01:12 ID:OGV1dpwn(1/2) AAS
>>242
-mm は、マゾ・マニア用。

上下前次 1-新書関写板覧索設栞歴

あと 712 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.026s