[過去ログ]
/**ファイルシステム総合スレ その7**/ (955レス)
/**ファイルシステム総合スレ その7**/ http://mao.5ch.io/test/read.cgi/linux/1173530292/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
147: login:Penguin [sage] 2007/03/29(木) 22:47:02 ID:EvQbMu8q エクステントって昔からエクステントと呼んでいたような。 VxFS とか。 http://mao.5ch.io/test/read.cgi/linux/1173530292/147
148: login:Penguin [sage] 2007/03/29(木) 23:07:03 ID:R0MPJnFu >>147 XFSのオンラインデフラグがext4についてくれれば、とりあえず最強なんだがな。 年に数回はデフラグしたい。 http://mao.5ch.io/test/read.cgi/linux/1173530292/148
149: login:Penguin [] 2007/03/30(金) 09:25:09 ID:8SUX2/zw MSDOSは複数のセクターをまとめた「クラスタ」という連続領域単位でファイルを管理してた。 インデックスを少なく押さえることと、断片化を少なくするのが目的。 低速媒体のフロッピーが主体だったため、断片化を避けるのは非常に重要だったせいもあるが 当時の大型機からの借用だったと理解してる。 エクステントの説明をみると同じものにみえるのだけど、何かちがうのだろうか? http://mao.5ch.io/test/read.cgi/linux/1173530292/149
150: login:Penguin [sage] 2007/03/30(金) 11:23:58 ID:TnuWXj4a >>149 クラスタサイズが可変なんじゃね? http://mao.5ch.io/test/read.cgi/linux/1173530292/150
151: login:Penguin [] 2007/03/30(金) 12:54:00 ID:8SUX2/zw それをどうやって決めてるかが肝 http://mao.5ch.io/test/read.cgi/linux/1173530292/151
152: login:Penguin [sage] 2007/03/30(金) 14:53:28 ID:1nTHIbAF エクステントサイズが固定の方が断片化は起こり肉印とちゃう? http://mao.5ch.io/test/read.cgi/linux/1173530292/152
153: login:Penguin [sage] 2007/03/31(土) 00:34:21 ID:MhCzl/tA >>149 ブロック管理だと ファイルが巨大になると インデックスを引くのに時間がかかるようになるが エクステント管理だとうまく連続ブロックに配置できれば時間が節約できる。 http://mao.5ch.io/test/read.cgi/linux/1173530292/153
154: login:Penguin [sage] 2007/03/31(土) 01:12:12 ID:ifE6Hzsr インデックスってエクステント単位で振られるんじゃないの? ブロック=IO最小単位 エクステント=領域割当最小単位 っていう理解で基本的にはいいんだよね? http://mao.5ch.io/test/read.cgi/linux/1173530292/154
155: login:Penguin [sage] 2007/03/31(土) 02:18:24 ID:cMH9eCiA 違う。 エクステントってのは連続したブロックのこと。 あるファイルが1〜10、15〜20のブロックからなっている時、ブロックベースの ファイルシステムでは (1 2 3 4 5 6 7 8 9 10 15 16 17 18 19 20) という インデックスで表現するのに対し、エクステントベースのファイルシステムでは ((1 10) (15 5)) のように表現する。 http://mao.5ch.io/test/read.cgi/linux/1173530292/155
156: login:Penguin [sage] 2007/03/31(土) 07:52:26 ID:Ud+o/4Fl >>155 inodeが圧縮できる?よくわかってませんが。 http://mao.5ch.io/test/read.cgi/linux/1173530292/156
157: login:Penguin [] 2007/04/01(日) 08:47:20 ID:jgewp6D4 で、最初の疑問ですが、 断片化が起こるのは、ファイル更新時のサイズ変化が要因だとすれば、 あらかじめ変化量を予測してエクステントを確保する必要があるわけだけど どうやるのですか? http://mao.5ch.io/test/read.cgi/linux/1173530292/157
158: login:Penguin [sage] 2007/04/01(日) 09:20:52 ID:Miicym17 extentの仕組みについて人に聞く前にまずググってみました。 ズバリというページがありません! http://www.spa.is.uec.ac.jp/~kinuko/survey/body/extent-like-fs.html http://www.kyoto-sr.co.jp/products/fugue/techinfo/fs-gc.html http://www.atmarkit.co.jp/flinux/rensai/oracle04/oracle04.html http://www.simosimo.info/know/oracle/extent.htm いったいエクステントについてよく理解するためにはどうしたらいいのか! 参考書とか専門書とか買わないとわからんかな。 http://mao.5ch.io/test/read.cgi/linux/1173530292/158
159: login:Penguin [sage] 2007/04/01(日) 11:10:36 ID:5ZbsiFAt >>158 くっつく?ひっつけばチャクラエクステントが発動します。 http://mao.5ch.io/test/read.cgi/linux/1173530292/159
160: login:Penguin [sage] 2007/04/01(日) 18:24:10 ID:AzuElS/P >>157 ジャーナルから commit するまで割り当てを遅延する ディスクの空き容量が少なくなるまでファイルを密に配置しない その他色々 http://mao.5ch.io/test/read.cgi/linux/1173530292/160
161: login:Penguin [sage] 2007/04/02(月) 09:07:01 ID:NH19NaTw ありがとうございます! しかしジャーナルに書き込むのは更新時が主ですよね? とすれば、新規作成時に将来サイズの予測ができることがエクステントの考え方としては最重要という気がします。 ファイルを密に配置しないという方針は有効ですが、エクステントとは別の考え方ではないでしょうか? http://mao.5ch.io/test/read.cgi/linux/1173530292/161
162: login:Penguin [] 2007/04/04(水) 09:53:19 ID:NWetzSkB 自己レスです。 エクステントの大きさは使用者が決めるようです。 しかも初期と伸張分をべつの大きさにする方法もあるようです。 したがって、設計段階でのサイズ予測はいらないということのようです。 http://mao.5ch.io/test/read.cgi/linux/1173530292/162
163: login:Penguin [] 2007/04/05(木) 11:44:51 ID:6CwC0rrT XSFフォーマットのディスクに入れたファイルとかを NTFSフォーマットのWINDOWSへコピーした場合普通に開けるのですか? http://mao.5ch.io/test/read.cgi/linux/1173530292/163
164: login:Penguin [sage] 2007/04/05(木) 13:15:06 ID:OdzCRDEa >>163 なぜ、自分で試さない? http://mao.5ch.io/test/read.cgi/linux/1173530292/164
165: 163 [] 2007/04/05(木) 13:24:15 ID:6CwC0rrT パソコンすら持ってないんです うぅ・・ http://mao.5ch.io/test/read.cgi/linux/1173530292/165
166: login:Penguin [sage] 2007/04/05(木) 13:30:30 ID:UHEFuWv5 そんな人が聞いてどうすんだろ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/166
167: 名無しさん@お腹いっぱい [] 2007/04/05(木) 15:20:22 ID:BtA25953 流行りのエアギターならぬエアLinuxってやつだな。 http://mao.5ch.io/test/read.cgi/linux/1173530292/167
168: login:Penguin [sage] 2007/04/05(木) 16:26:00 ID:xu52r8kl 俺の若い頃は藁半紙に書いたキーボードとライオン本でカーネルハックの練習をしたもんだよ http://mao.5ch.io/test/read.cgi/linux/1173530292/168
169: login:Penguin [sage] 2007/04/05(木) 17:40:51 ID:ArTajbou エアオナニー http://mao.5ch.io/test/read.cgi/linux/1173530292/169
170: login:Penguin [sage] 2007/04/05(木) 23:16:24 ID:jNYQCAbT 牛乳石鹸をマウスに見立てて、X Windowへの思いをはせたもんだ http://mao.5ch.io/test/read.cgi/linux/1173530292/170
171: 81 [] 2007/04/06(金) 04:19:45 ID:kERYUymx mount -o mount,ro / がbusy で帰ってきて困ってた81(80と間違えてた)です。 2週間ほどたってやっと再現されました。 しかもラッキーに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 大切なのは最初の1行で以下のprintkから出力されました。 fs/file_table.c: int fs_may_remount_ro(struct super_block *sb) { struct list_head *p; ... /* File with pending delete? */ if (inode->i_nlink == 0) { printk(KERN_NOTICE "fs_may_remount_ro found pending delete: 0x%x¥n", (unsigned long)file); goto too_bad; } 続く http://mao.5ch.io/test/read.cgi/linux/1173530292/171
172: 81 [sage] 2007/04/06(金) 04:29:08 ID:kERYUymx さて、まずどのファイルか? 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" もうここで は〜〜〜あ〜〜〜〜??????? です。なんでライブラリー ファイルがpending delete なの???? http://mao.5ch.io/test/read.cgi/linux/1173530292/172
173: 81 [sage] 2007/04/06(金) 04:41:28 ID:kERYUymx もうちょっと掘り下げる。 (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 ??? 食い違うぞ ??? 誰がこのファイルを開いてる? # lsof | grep libz.so.1.2.1.2 # ちょっと冗長な行は省いてます postmaste 5377 initrfx mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 snmpd 5580 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 ntpd 21393 ntp mem REG 3,3 230991 /usr/lib/libz.so.1.2.1.2 (path inode=231021) sshd 26062 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 sshd 26066 admin mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 sshd 26135 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 sshd 26153 support mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2 ここでntpdに注目、他のプロセスは正しいinodeで開いているのにntpdだけがこの問題の 230991番のinodeを通して開いてます。 http://mao.5ch.io/test/read.cgi/linux/1173530292/173
174: 81 [sage] 2007/04/06(金) 04:50:49 ID:kERYUymx それでもって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) ntpd 21393 ntp mem REG 3,3 195438 /lib/libcap.so.1.10 (path inode=194186) ntpd 21393 ntp mem REG 3,3 230991 /usr/lib/libz.so.1.2.1.2 (path inode=231021) ntpd 21393 ntp mem REG 3,3 194184 /lib/libresolv-2.3.4.so (path inode=195487) ntpd 21393 ntp DEL REG 3,3 230821 /usr/lib/libgssapi_krb5.so.2.2.#prelink#.k1YsQi ntpd 21393 ntp mem REG 3,3 195446 /lib/ld-2.3.4.so (path inode=195478) ntpd 21393 ntp mem REG 3,3 230734 /usr/lib/libk5crypto.so.3.0 (path inode=230968) ntpd 21393 ntp mem REG 3,3 210597 /lib/tls/libm-2.3.4.so (path inode=210654) ntpd 21393 ntp DEL REG 3,3 195456 /lib/libcrypto.so.0.9.7a.#prelink#.7KiFJi 以下略。 続く http://mao.5ch.io/test/read.cgi/linux/1173530292/174
175: 81 [sage] 2007/04/06(金) 04:52:02 ID:kERYUymx ちなみに正常(?)な状態の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 ntpd 2101 ntp mem REG 3,2 47468 258705 /lib/libnss_files-2.3.4.so ntpd 2101 ntp mem REG 3,2 112236 294966 /lib/ld-2.3.4.so ntpd 2101 ntp mem REG 3,2 63624 247059 /usr/lib/libz.so.1.2.1.2 ntpd 2101 ntp mem REG 3,2 213992 260979 /lib/tls/libm-2.3.4.so ntpd 2101 ntp mem REG 3,2 136016 242425 /usr/lib/libk5crypto.so.3.0 ntpd 2101 ntp mem REG 3,2 81184 260981 /lib/libresolv-2.3.4.so ntpd 2101 ntp mem REG 3,2 7004 260980 /lib/libcom_err.so.2.1 ntpd 2101 ntp mem REG 3,2 82944 247067 /usr/lib/libgssapi_krb5.so.2.2 以下略。 http://mao.5ch.io/test/read.cgi/linux/1173530292/175
176: 81 [sage] 2007/04/06(金) 04:56:47 ID:kERYUymx ちなみにこの症状は問題のおこった2つのシステムでまったく同じ。 おなじlibz.soでひっかかり、やはりntpが同じような状態になってます。 さて、この"path inode"というのがキモのようですが、なんの事か 全然分からないからどこかで調べてきます。 ここまでの情報で何か助言があればよろしくおねがいします。 http://mao.5ch.io/test/read.cgi/linux/1173530292/176
177: 81 [sage] 2007/04/06(金) 05:25:18 ID:kERYUymx なお、問題のあるシステムでは問題のあるのはntpだけでありません。 # lsof | grep "path inode" | cut -d" " -f1 | sort | uniq agetty crond ifplugd klogd mingetty ntpd portmap syslogd udevd xinetd 問題のないシステムではこの"path inode"は全く見受けられません。 それから これらのシステムではライブラリーのアップデートは全く行われてません。 http://mao.5ch.io/test/read.cgi/linux/1173530292/177
178: login:Penguin [sage] 2007/04/06(金) 05:46:22 ID:lKLkq3ZS prelinkによってロード中の共有ライブラリが置き換えられているのかな? prelinkを止めてみるとか。 http://mao.5ch.io/test/read.cgi/linux/1173530292/178
179: 81 [sage] 2007/04/06(金) 06:12:19 ID:kERYUymx >>178 そっ、それだ〜〜〜〜〜〜〜〜〜〜〜〜。 こんなもの見つけました。 /etc/cron.daily/prelink 一発で再現出来ました。 正常状態: # touch /hoge touch: cannot touch `/hoge': Read-only file system # lsof | grep "path inode" | wc -l 0 再現: # mount -o remount,rw / # /etc/cron.daily/prelink # mount -o remount,ro / mount: / is busy # lsof | grep "path inode" | wc -l 337 よーするにこれが滅多に起きなかったのは、普段はr/oなのでprelinkは水面下でエラーを起こして たのでしょうが、たまにr/wに変わる短い時間がcron.dailyとぶつかることがあるのでしょう。 その時に書き換えられてこうなると。 しかしprelinkって乱暴ですね。 http://mao.5ch.io/test/read.cgi/linux/1173530292/179
180: login:Penguin [sage] 2007/04/06(金) 06:56:25 ID:lKLkq3ZS オープン中のファイルは移動したり削除しても影響を受けないから、prelink の 動作自体は乱暴でもないような。 lsof の出力に path inode が出ているのは、オープン中に置き換えられたファイルで ある事を示しているのを初めて知ったから俺も勉強になったよ。 問題が解決して良かったね。 http://mao.5ch.io/test/read.cgi/linux/1173530292/180
181: 81 [sage] 2007/04/06(金) 07:16:47 ID:kERYUymx >>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 # lsof | grep hoge.txt cat 9317 root 1w REG 253,0 0 15 /hoge.txt (deleted) http://mao.5ch.io/test/read.cgi/linux/1173530292/181
182: login:Penguin [sage] 2007/04/07(土) 00:19:04 ID:PW/Wm1N9 よくそこまで調べたなー /proc/kcoreをgdbに繋ぐなんてテクニック初めて知った すげぇわ http://mao.5ch.io/test/read.cgi/linux/1173530292/182
183: login:Penguin [sage] 2007/04/07(土) 00:22:14 ID:l0bc2a+o >>182 /proc/kcoreはgdbで使うための仮想ファイルだろ? http://mao.5ch.io/test/read.cgi/linux/1173530292/183
184: login:Penguin [sage] 2007/04/07(土) 05:48:12 ID:07BPrRWv http://www.gentoo.org/doc/ja/prelink-howto.xml 4. 既知の問題と解決策 http://mao.5ch.io/test/read.cgi/linux/1173530292/184
185: login:Penguin [sage] 2007/04/07(土) 15:32:22 ID:w4EDI2Lw 怠け者な俺は、locateとかprelinkなんて余計なものは真っ先に外しちゃうからなぁ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/185
186: login:Penguin [sage] 2007/04/07(土) 21:33:30 ID:Vx40DlGH >>185 locateの便利さがわからんか。 デスクトップ検索の先駆けだぞ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/186
187: login:Penguin [sage] 2007/04/07(土) 21:37:40 ID:qEROFzP6 ファイルシステムってハマる時はハマるのだな…。 自分ならとても解決できなかったように思う。 locateは入っていたがprelinkは入れてなかったので入れようかと思っていたが、 こんな理解不能の事態が発生するのでは、いれていいかどうか不安に感じてしまう…。 http://mao.5ch.io/test/read.cgi/linux/1173530292/187
188: login:Penguin [sage] 2007/04/08(日) 00:43:17 ID:HNNwKpZg >>186 だって全然使わない、デスクトップ検索自体しないし・・・ GoogleDesktop入れて気付いたが 広大なwebならともかく自分の管理してる所なんだから 情報はちゃんと整理してる、というかしていないときもちわるい Spotlightも使わない なのでlocateのありがたみもよく解らんです http://mao.5ch.io/test/read.cgi/linux/1173530292/188
189: login:Penguin [sage] 2007/04/08(日) 00:50:38 ID:S1gIGviP >>188 /home以下じゃなくて、使ったこと無いコマンドとかインストールされているか 調べるために、 locate hoge とか実行する。 というか、「お前は自分の管理してるマシンのファイル名を全部覚えているのか?」 もしやっているならご苦労なことだ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/189
190: login:Penguin [sage] 2007/04/08(日) 01:46:07 ID:+N5qr5Yv コマンドなら、whichでいいだろ。 locateなんてわざわざ使わん。 http://mao.5ch.io/test/read.cgi/linux/1173530292/190
191: login:Penguin [sage] 2007/04/08(日) 01:49:51 ID:S1gIGviP >>190 パス通してない無い場合は? コマンドは例だったが適用例は設定ファイルとかファイル全般。 http://mao.5ch.io/test/read.cgi/linux/1173530292/191
192: login:Penguin [sage] 2007/04/08(日) 01:54:57 ID:AO6opwfy 俺はwhichもlocateも使うよ。 locateはかなり良く使うけどなぁ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/192
193: login:Penguin [sage] 2007/04/08(日) 02:34:25 ID:Hzw/JAkU cronでslocate走った後って、メモリ消費量増えない? http://mao.5ch.io/test/read.cgi/linux/1173530292/193
194: 81 [sage] 2007/04/08(日) 04:25:29 ID:HBM8UdKZ >>187 いや、自分の場合はrootをr/oにするというハックをしている状況なのでハマっただけです。 組み込み系のアプライアンスのための要求なので普通のホストシステムならたぶん問題はないでしょう。 しかし今回の経験で学んだのは、Linuxホストのrootをr/oにするっていうノウハウがあまり 確立されてないという事。漠然とセキュリティーのためにそうする事もあるという事を 見聞きしてましたが、今回のことも含め、ハマる穴は沢山ありそうです。 http://mao.5ch.io/test/read.cgi/linux/1173530292/194
195: login:Penguin [sage] 2007/04/08(日) 04:34:17 ID:IVjfIv3g >>194 BSDに比べて/をroにすることを考えていないといえば考えて無いとはいえると思う。 prelinkとかは止めりゃいいだけだが、 /usr のパーティション分けたら動かないものとかあったりするし。 http://mao.5ch.io/test/read.cgi/linux/1173530292/195
196: login:Penguin [sage] 2007/04/08(日) 05:55:52 ID:VhLkTwV9 というか、cronでprelinkなんか動かしているその組込み系の ディストリを明記してくれた方が有益だと思う。 あるいは、PC向けのディストリをベースに自力で構築している ならそう書くべきだな。 http://mao.5ch.io/test/read.cgi/linux/1173530292/196
197: login:Penguin [sage] 2007/04/08(日) 09:31:32 ID:M3c2/sEX >>193 > cronでslocate走った後って、メモリ消費量増えない? ファイルキャッシュが増えるからだよ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/197
198: 81 [sage] 2007/04/08(日) 12:57:04 ID:HBM8UdKZ >>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 fi これ見たとき、お、ちゃんと考えてるじゃんとか思ったのですが、肝心の/etc/rc.readonlyがないんですよね。 "magic stuff"は自分で書いてくれとのことのようです。 http://mao.5ch.io/test/read.cgi/linux/1173530292/198
199: login:Penguin [sage] 2007/04/08(日) 13:04:09 ID:v21r+S80 >>194 ひとりでこつこつとやっててもむずかしいよ。 組込み系は組込み系のコミュニティーで ノウハウが貯ってるからねぇ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/199
200: login:Penguin [sage] 2007/04/08(日) 14:22:45 ID:Q1EoOsla システム全体に全文検索のindexを作るのは現実的じゃないからファイル名検索は現役だけど、 slocateはupdatedbを実行するまでindexが更新されないのが困る。updatedbの実行中は負荷高いし モジュールの追加に抵抗が無ければ、ディレクトリツリーを変更するシステムコールをフックして、 インデックスを即時変更するrlocateの方がスマート http://mao.5ch.io/test/read.cgi/linux/1173530292/200
201: login:Penguin [sage] 2007/04/08(日) 14:56:06 ID:+N5qr5Yv updatedb重いよなぁ。 デュアルコアとかマルチプロセッサなら多少は軽減されるだろうか? ま、どっちにしてもサーバ向けの機能ではないし、いらないっちゃいらない。 http://mao.5ch.io/test/read.cgi/linux/1173530292/201
202: login:Penguin [] 2007/04/08(日) 15:25:07 ID:ZmJtdjLW 重いと感じない私は使い方間違ってる? 動作中は確かにディスクアクセスが増えるけど、CPUそんなに使わないし 五分もしないうちに終わるし。 ディスク合計1テラ弱を八割程度しか使ってないから? システムはP4HT2.8G SATAディスク500GB+400GBです http://mao.5ch.io/test/read.cgi/linux/1173530292/202
203: login:Penguin [sage] 2007/04/08(日) 18:21:11 ID:kS1N8DBw updatedb って中身は主として find を呼び出している シェルスクリプトとして実装されていることが多いですよね。 nice したらそんなに邪魔にならないし、 そんなに邪険にしてやらなくてもいいんじゃないだろうか。 http://mao.5ch.io/test/read.cgi/linux/1173530292/203
204: login:Penguin [sage] 2007/04/08(日) 21:30:08 ID:IVjfIv3g >>201 サーバとデスクトップで区別する理由が分からん。 どっちでも有用だろ。 手動実行しても重たいとは思わないが、 普通はcronでniceつきで回すだろうから全く問題ない。 >>200 rlocateって標準装備してるdist.ってある? http://mao.5ch.io/test/read.cgi/linux/1173530292/204
205: login:Penguin [sage] 2007/04/08(日) 21:50:06 ID:zsJ2r/Ru ちょっと前にさ、locateが速いのはホントにupdatedbのおかげなのか?と思って ・普通にupdatedb + locate ・単なるfind | gzip > list.gz + zgrep で比較してみた。 そしたら、なんとfind + zgrepの方が、というかlocateよりも zgrepでリストファイル検索した方が速かった。リスト作るのも 当然findのみの方が速い。updatedbは内部でデータベース作ってる わけだけど、スペース削減の意味がほとんどない今、もう過去の 遺物かも知れんと思ったよ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/205
206: login:Penguin [sage] 2007/04/08(日) 22:05:50 ID:EmYGF54Z 過去の遺物だろうね。 fedoraではFC3あたりからlocateのサービスが切られてるよ。 それ以前はデフォルトでcronで走るようになってたけど。 http://mao.5ch.io/test/read.cgi/linux/1173530292/206
207: login:Penguin [sage] 2007/04/08(日) 22:08:33 ID:dD+lSYL+ makewhatisも切ってほしい http://mao.5ch.io/test/read.cgi/linux/1173530292/207
208: login:Penguin [sage] 2007/04/08(日) 22:44:55 ID:tkpoMrl5 >>205 なんかオレが調べた結果と違うなあ。(ただしFreeBSD上) 手元のPCはディレクトリとか込みで200万ぐらいファイルがあるんだけど、 zgrepで調べたほうが遅くなる。 アルゴリズム的にファイル数が増えるにしたがって差が開くはず。 locateのデータベースはファイルリストをソートし、一つ前のファイルパスと 異なる部分からしか記録してないのでファイルサイズが小さい。 しかも、検索する際にスキャンするデータの大きさはlocatedbのサイズ分だけ ですむ。 gzipしたファイルを検索する場合は元のファイルの大きさ分スキャンしないと いけなくなる。 ちなみにファイルサイズはlocatedbだと17MB弱、gzipものは18M強、 bzip2だと15MB強でどれもほとんど変わらんかった。 元のファイルリストは200MBぐらい。 検索時間はlocateだと0.19s、zgrep, zfgrepだと1.45sぐらい、 bzgrep, bzfgrepだと12s弱ってところ。 ためしに元のファイルでgrepかけてみると0.26sぐらい。 (Pentium4 2.8GHz, FreeBSD 6.1) もちろん、rlocateみたいにファイルの名前が変更されたときにデータベースを 更新するのが一番いいけど。 http://mao.5ch.io/test/read.cgi/linux/1173530292/208
209: login:Penguin [sage] 2007/04/08(日) 23:31:08 ID:HNNwKpZg みんなそんなにファイル調べる事あるの? >>189 コマンドインストールしてるかなら、パッケージ管理用のコマンド使うし 自分がパスを通している所以外にコマンドが入っていることなんてまず無いし・・・ で、動的なファイル検索ならfindを使う。 色々調べ方を指定できるfindの方が便利だし。 つまり、偶にしか使わない機能だから、ちょっと位速くなっても・・・という気分。 http://mao.5ch.io/test/read.cgi/linux/1173530292/209
210: login:Penguin [sage] 2007/04/08(日) 23:39:41 ID:S1gIGviP >>209 一般ユーザで find / するとパーミッションで読めないファイルあるでしょ。 (これはlocateも同じ問題が発生するが) わざわざ毎回 find / することを防ぐために locatedb 作ってるんだからさ。 locatedb 更新後に追加したら、updatedb 実行すればいいだけだし。 http://mao.5ch.io/test/read.cgi/linux/1173530292/210
211: login:Penguin [sage] 2007/04/08(日) 23:43:21 ID:zsJ2r/Ru >>208 こっちはLinux。規模はやっぱり200万ちょっとくらい。 updatedbのデータはもう作らなくなってしまったので今追試は できないけど、データ構造的にはupdatedbの方が高速になるはずと いうのは同意。でも、結果はそうでなかったので「?」だった。 「.」で探して全スキャンとかしてみるとどう? >>209 大抵のファイルのありかは頭に入っているわけなので、 調べる必要がある時は「わからーん」という状況のことが多い。 そういう時にfindではターンアラウンド大きすぎて試行錯誤できず 不便なことがある。locate,locate,locate。。。あった、位に高速でないと。 でも、最近はファイルシステム構成やパッケージ構造が標準化されて あまり出番はなくなった>locate http://mao.5ch.io/test/read.cgi/linux/1173530292/211
212: login:Penguin [sage] 2007/04/08(日) 23:52:15 ID:tkpoMrl5 ソースとか溜め込んでるとlocateは便利だよ。 例えば前にコンパイルしたバージョンほげほげのtarballはどこいったって感じで。 あとconfigureでライブラリとかヘッダーファイルがないって言われたときも結構使うね。 Perlのモジュール使ってるときにも元の.pmファイルが見たいときがあるんで使うなあ。 なんとなくだけど、自分でコンパイルしない人はlocate使わないのかも。 http://mao.5ch.io/test/read.cgi/linux/1173530292/212
213: login:Penguin [sage] 2007/04/08(日) 23:58:51 ID:FgPsXoOH >>212 findだと大変だもんね。 http://mao.5ch.io/test/read.cgi/linux/1173530292/213
214: login:Penguin [sage] 2007/04/08(日) 23:59:33 ID:+N5qr5Yv 自分でコンパイルするときはどこに何が置かれるのかおよそ把握するし。 ログを残しておけば、それを見ることも出来るし。 コンパイル専用ユーザとか作るのも普通でしょ? http://mao.5ch.io/test/read.cgi/linux/1173530292/214
215: login:Penguin [sage] 2007/04/09(月) 00:04:14 ID:tkpoMrl5 >>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 しかもfgrepのほうが遅い。 (fgrepが遅い理由はググれば出てくるはず) http://mao.5ch.io/test/read.cgi/linux/1173530292/215
216: login:Penguin [sage] 2007/04/09(月) 00:05:37 ID:atKY9uJN >>214 小規模かつ一人でやってんならそうでしょうね。 http://mao.5ch.io/test/read.cgi/linux/1173530292/216
217: login:Penguin [sage] 2007/04/09(月) 00:06:18 ID:vrz2OUFg >>214 tarball内のファイル名全部を記憶してるわけ? log取ったあとに移したりすると意味無いから、 ログより新しい情報で無いと使えないことがある。 http://mao.5ch.io/test/read.cgi/linux/1173530292/217
218: login:Penguin [sage] 2007/04/09(月) 00:12:46 ID:YK4Cy17y locateは使った時に便利さが実感できるけど 使わない時は本当に使わないね。 半年くらい前にサウンドデバイスのテストしようとして locate "*wav" したのが最後だ。 cronで毎日更新してるけどなんかもったいないな。 http://mao.5ch.io/test/read.cgi/linux/1173530292/218
219: login:Penguin [sage] 2007/04/09(月) 00:15:11 ID:atKY9uJN >>218 まぁ、いいんじゃない? http://mao.5ch.io/test/read.cgi/linux/1173530292/219
220: login:Penguin [sage] 2007/04/09(月) 00:17:37 ID:PFZ7GF/k あー、locateバリバリ使わないとどうにもならなかった事例思い出した。 前任者が勝手コンパイルで入れたsenmdmailの入れ替え。 インストールログが一切なくて、そこらじゅうのマシンのいろんなディレクトリに展開されてる sendmailの内、どれを使ってコンパイルしたのか分からない。 仕方ないからマシン全てでlocateを実行しましたよ。 findだと日が暮れてたと思う。 結局、コンパイルに使ったソースファイルはどこにもなかったけど。 http://mao.5ch.io/test/read.cgi/linux/1173530292/220
221: login:Penguin [sage] 2007/04/09(月) 00:19:05 ID:YC9/TDq9 locate 使うかどうかなんて議論するほどのことか? 便利だと思うなら使えばいいし、 必要ないと思うなら使わなきゃいい。 どうしてもやりたいなら雑談スレでやってくれ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/221
222: login:Penguin [sage] 2007/04/09(月) 00:23:53 ID:atKY9uJN >>221 うっせぇよ。どんだけ偉いんだお前? http://mao.5ch.io/test/read.cgi/linux/1173530292/222
223: login:Penguin [sage] 2007/04/09(月) 00:41:27 ID:SYt9P2O4 自分で管理もしてないPCの locate の結果が信用できるのかね。 しかもそんな状態の。 http://mao.5ch.io/test/read.cgi/linux/1173530292/223
224: login:Penguin [sage] 2007/04/09(月) 00:45:52 ID:atKY9uJN >>223 >自分で管理もしてないPCの locate の結果が信用できるのかね。 言い出したら1日前のファイルリストなんぞなんの信頼性もない。 その正当性は人が確認すればいい話。 何もlocate hoge | xargs rm -rfなんてことがしたいわけじゃないし。 ファイルが今もその辺にあることを「知りたい」だけなんだよ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/224
225: login:Penguin [sage] 2007/04/09(月) 00:54:15 ID:PFZ7GF/k locateの機能をファイルシステム側で提供してくれるとうれしいと思わないかい? rlocateのやり方だとリモートディスクが変更された場合に検索できなくなるから、 ファイルシステムの機能として取り込んでくれないかなあ。 ぶっちゃけ頓挫したWinFSみたいにDBにメタデータつっこんでくれれば、 なんでもし放題でいいんだけどなあ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/225
226: login:Penguin [sage] 2007/04/09(月) 00:56:08 ID:b08awD+c beagleとか大して使われなかったな http://mao.5ch.io/test/read.cgi/linux/1173530292/226
227: login:Penguin [sage] 2007/04/09(月) 02:22:01 ID:EXUr/7hN 単純圧縮だと時間が線形に増えるのに対し、 木検索だとlog2になるので、数が増えれるほど差が開く。 線形検索だと処理が単純な分オーバーヘッドが少ないので、 数が少ない場合は線形の方が速いし、数が多くなれば木の方が速くなるだろ。 更に、パイプでつなげて複数のプロセッサを同時に使えるケースだと単純2倍になるとか、 条件変数をいじれば閾値が変わる。 比較するなら条件付けないと意味なさげ http://mao.5ch.io/test/read.cgi/linux/1173530292/227
228: login:Penguin [sage] 2007/04/09(月) 12:40:13 ID:jp1FtvCv reiser,reiser騒ぐヤツはどこでも疎まがられてますな。 (Reiser4. BEST FILESYSTEM EVER.) http://mao.5ch.io/test/read.cgi/linux/1173530292/228
229: login:Penguin [sage] 2007/04/09(月) 12:50:11 ID:F3Ij9AuO 彼らが亡き者にされないことを祈ります http://mao.5ch.io/test/read.cgi/linux/1173530292/229
230: login:Penguin [sage] 2007/04/09(月) 13:34:58 ID:jp1FtvCv >REISER4 FOR INCLUSION IN THE LINUX KERNEL. 危な臭くなってきますた。 http://mao.5ch.io/test/read.cgi/linux/1173530292/230
231: login:Penguin [] 2007/04/09(月) 13:53:01 ID:72H5EoZf どこに書かれていますか http://mao.5ch.io/test/read.cgi/linux/1173530292/231
232: login:Penguin [sage] 2007/04/09(月) 14:06:24 ID:2R5UgYQX Reiserの事件が起きたのが不思議だったが このスレの速度見てたら納得した。 Linuxに於いてファイルシステムは重要な位置にある。 Reiser裁判の続報マダー? http://mao.5ch.io/test/read.cgi/linux/1173530292/232
233: login:Penguin [sage] 2007/04/09(月) 15:53:55 ID:jlcenkeg SCO裁判と合流いたします。 http://mao.5ch.io/test/read.cgi/linux/1173530292/233
234: ◆IIiDC8JS7w [sage] 2007/04/10(火) 01:12:20 ID:7nQI0l/r 4/6からreiser4のお話でLKMLが荒れてます。 お話はベンチマークでreiser4最強説から始まる。。。 BEST FILESYSTEM EVER. ttp://marc.info/?t=117582320300003&r=1&w=2 ttp://marc.info/?t=117606890500003&r=1&w=2 REISER4 FOR INCLUSION IN THE LINUX KERNEL. ttp://marc.info/?t=117609196200002&r=1&w=2 Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE ttp://marc.info/?t=117611593400001&r=1&w=2 http://mao.5ch.io/test/read.cgi/linux/1173530292/234
235: login:Penguin [] 2007/04/10(火) 09:09:09 ID:TLRAIA8b mmカーネルには入ってるのだから、 メインストリームに入れられない理由が技術的問題なんてありえない。 http://mao.5ch.io/test/read.cgi/linux/1173530292/235
236: login:Penguin [sage] 2007/04/10(火) 17:24:13 ID:SKiObrIB >>235 ここまで大きくなると、政治も技術なんだよね。 http://mao.5ch.io/test/read.cgi/linux/1173530292/236
237: login:Penguin [sage] 2007/04/10(火) 17:35:34 ID:NbCL9/FB 単にコミュニケーション能力だろ? http://mao.5ch.io/test/read.cgi/linux/1173530292/237
238: login:Penguin [sage] 2007/04/10(火) 18:39:10 ID:72LWlPWO メインストリームに入れたとして誰がメンテナになるの? 一緒に変更されるIO周りのメンテナンスは? 入れて終わり、じゃないから難しい http://mao.5ch.io/test/read.cgi/linux/1173530292/238
239: login:Penguin [sage] 2007/04/10(火) 22:20:54 ID:WYQ/GLOl >>238 俺だけど? http://mao.5ch.io/test/read.cgi/linux/1173530292/239
240: login:Penguin [sage] 2007/04/10(火) 22:51:49 ID:SKiObrIB >>239 お前じゃぁ、やっぱり見込み無いな・・・。 http://mao.5ch.io/test/read.cgi/linux/1173530292/240
241: login:Penguin [sage] 2007/04/10(火) 23:22:07 ID:epWNgzd4 akpmなら、akpmならやってくれる!! http://mao.5ch.io/test/read.cgi/linux/1173530292/241
242: login:Penguin [sage] 2007/04/10(火) 23:45:53 ID:meYFnXcY mm=マジ ムカツク http://mao.5ch.io/test/read.cgi/linux/1173530292/242
243: login:Penguin [sage] 2007/04/11(水) 01:12:31 ID:OGV1dpwn >>242 -mm は、マゾ・マニア用。 http://mao.5ch.io/test/read.cgi/linux/1173530292/243
244: login:Penguin [sage] 2007/04/11(水) 01:28:22 ID:SCjN+X9I Reiser4の最強性能を使いたくないとは 判り易すぎる工作員だよな。 きなくさいどころか大炎上ものだろ。 反対するやつら尋問して黒幕吐かせろよ。 http://mao.5ch.io/test/read.cgi/linux/1173530292/244
245: login:Penguin [sage] 2007/04/11(水) 02:36:47 ID:veJPWDy0 >>244 ちょいと聞きますが「Reiser4の最強性能」って具体的にどんなもんですか 新規インストールするノートPCにどのFS使おうか迷ってるもので参考の為お伺いします http://mao.5ch.io/test/read.cgi/linux/1173530292/245
246: login:Penguin [sage] 2007/04/11(水) 06:27:12 ID:JLZuygxe とりあえずチキンな俺は ext3 だな。 http://mao.5ch.io/test/read.cgi/linux/1173530292/246
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 709 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.021s