[過去ﾛｸﾞ]
/**ファイルシステム総合スレ その3**/ (983ﾚｽ)
/**ファイルシステム総合スレ その3**/ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
587: login:Penguin [sage] 2005/06/11(土) 10:46:04 ID:YBm7Ac5C OS自体を楽しむためのOSだから、それでいいんじゃない？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/587
588: login:Penguin [sage] 2005/06/11(土) 11:16:34 ID:QwwdnapJ 全部ext3(ext2)なんて耐えられない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/588
589: login:Penguin [sage] 2005/06/11(土) 11:49:07 ID:k11yFVyv 適材適所なのは分かるが、具体的にどんなときに適してるかまとめてある資料ってない? reiserが小さいファイル、xfsが大きいファイルに適してるってのは知ってるんだが、 >>576が言うみたいな具体的なサイズまでは知らない。 どれくらいの大きさなら、ext3と同程度かそれ以上の性能が出せるのかが知りたいんだが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/589
590: login:Penguin [sage] 2005/06/11(土) 13:15:07 ID:1+AbN8Zx 速度しか見ようとしないから厨と言われるのだ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/590
591: login:Penguin [sage] 2005/06/11(土) 18:11:08 ID:tsyT4Q7w >>589 なんだかんだ言って、どのファイルシステムも 大きいファイルから小さいファイルまで考えて作ってある。 確かに、ファイルシステム自体の評価は余り見かけないね。 「 ext は断片化に強いからデフラグは不要 」 と 信じて疑わない人が大多数であるし。 結果は >>529 の一番下の資料を見る限り Windows と同様、 断片化の影響を大きく受けている。 疑わないことで Windows に遅れを取ったことになる。 サーバーマシンではデフラグの効果が余り無いのも事実だけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/591
592: login:Penguin [sage] 2005/06/11(土) 18:31:48 ID:hsNbI7ep ext2のデフラグツールって90年代前半には既にあっただろ Unixの「デフラグツールはありえない」っていう思い込みを 無批判にLinuxに適用していたアフォ評論家が多かっただけ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/592
593: login:Penguin [sage] 2005/06/12(日) 12:09:08 ID:WyDea27m ・fsckが早い ・使用環境のファイルサイズが大きいものが多い環境（1GB以上のファイル） ・そのファイルサイズが大きいファイルの削除が早い ・ランダムアクセスはほとんど発生しない ・MDデバイスやLVM上でもファイルシステムを構築できる ・ファイルシステムの拡張ができる（できれば縮小もできるとうれしいけど、その点は妥協） といった感じで現在SuSE Linux 8.2 (Kernel 2.4系）で XFSメインで使用しているのですが 最近（Kernel2.6環境）でも上記条件ではXFSにしておくのが無難ですかねぇ？ ログ見るとReiserFSがかなりよくなってるようですが・・・ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/593
594: login:Penguin [sage] 2005/06/12(日) 12:31:08 ID:L2jXqSZl >>593 >>・fsckが早い XFSのfsckのソースのmain()の中身って return 0; だけじゃなかったっけ? 今は違ってる? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/594
595: login:Penguin [sage] 2005/06/12(日) 14:06:10 ID:mDDN0cpU int main(int argc, char **argv) { return 0; } 先生！変わってませんでした！ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/595
596: login:Penguin [sage] 2005/06/12(日) 14:59:48 ID:vGQn+qRP > int > main(int argc, char **argv) > { > return 0; > } Hello World よりも酷いね・・ 早くLinuxででもUFS2を不自由なく使えるようになって欲しい。 UFS2は素晴しい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/596
597: login:Penguin [sage] 2005/06/12(日) 15:31:49 ID:rxgjWDEm >>596 何がうれしいの? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/597
598: login:Penguin [sage] 2005/06/12(日) 17:13:45 ID:xKpfalq4 しかし、reiserfs や ntfs とメジャーなものばっかりですなぁ。話題は。 漏れとしてはそれよか、他のシステムで使われているファイルシステムが気になるのだが...hfsとかhpfsとか まぁそっち側の趣味を持っている奴がいるのかいないのかぐらい確かめさせてくれ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/598
599: login:Penguin [sage] 2005/06/12(日) 17:33:37 ID:2UA783RA >>596 Linuxのことだから、一から再実装してext2と大してと変わらんシロモノになるぞ(w http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/599
600: login:Penguin [sage] 2005/06/12(日) 18:53:43 ID:44r2DxRg filesystemについて理解していないのならわざわざバカなこと書いて 無能を晒さなくてもいいのに。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/600
601: login:Penguin [sage] 2005/06/12(日) 19:11:52 ID:YlSd9RFt 600=真性包茎 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/601
602: login:Penguin [sage] 2005/06/12(日) 19:25:39 ID:jYbChQgW 真性包茎 = UFS 仮性包茎 = UFS + Softupdate ズルムケ = XFS, Reiserfs http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/602
603: login:Penguin [sage] 2005/06/13(月) 03:56:57 ID:TqaxjCvq 上の方がすぐれてるんだよな？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/603
604: login:Penguin [sage] 2005/06/13(月) 04:14:41 ID:KnVvvbwy >>603 真ん中が地球上の動物として普通。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/604
605: login:Penguin [sage] 2005/06/13(月) 08:11:39 ID:WmB6lfpd http://blog.livedoor.jp/shi3z/archives/24991969.html Re:ひとつのディレクトリに数十万個のファイル？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/605
606: login:Penguin [sage] 2005/06/13(月) 08:59:23 ID:2RWzgV4j そもそもXFSのfsckに何をさせようというのだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/606
607: login:Penguin [sage] 2005/06/13(月) 11:36:26 ID:rDElFmZS >>593 が言ってるfsckってjournal replayのことだろ… http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/607
608: login:Penguin [sage] 2005/06/13(月) 16:41:04 ID:u9pC4VSX >>605 要約すると 「ぼくは情報処理のべんきょうをしたことがありません」 「ぼくは悪くありません」 てことですね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/608
609: login:Penguin [sage] 2005/06/13(月) 23:57:22 ID:lEURqtLJ まあ、普通に考えてDBでやるだろうな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/609
610: login:Penguin [sage] 2005/06/14(火) 00:22:36 ID:wqoBv/5M >>609 んだな。 ところで今のサーバのメモリが2Gくらいって感覚はどうなの。 何のサーバかにもよるけど、最近なら8G位普通じゃない？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/610
611: login:Penguin [sage] 2005/06/14(火) 00:43:50 ID:/x4CkgdX >>610 鯖でなくてもデスクトップなら普通2Gくらい載せてるだろ。 4GoverだとM/BのスロットとOSが64bit対応してるのがmustだな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/611
612: login:Penguin [sage] 2005/06/14(火) 02:09:02 ID:LlAuHwpv >>605のリンク先の言い訳を見てると首がもげるぐらい傾くな。 8ビット機の昔から、ゲームで大量に使わなきゃいけないデータは単純に結合した１つのファイル にでもしておく手法が主流だったんじゃないか？ msec単位の処理時間を気にするなら、openよりseekの方が速いだろうに。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/612
613: login:Penguin [sage] 2005/06/14(火) 03:55:11 ID:yLaqsY1o >>612 確かに。違う画像とって来るにもopen-read-closeよりseek-readの方が速い http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/613
614: login:Penguin [sage] 2005/06/14(火) 03:55:13 ID:r5s7Eol3 >>611 デスクトップでは、まだ１Ｇでしょ。 熱心な人が２〜４Ｇにするくらいで。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/614
615: login:Penguin [sage] 2005/06/14(火) 10:54:34 ID:6JUgzPt7 ゲームする人は、結構2G多いかな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/615
616: login:Penguin [sage] 2005/06/14(火) 11:20:25 ID:4oeAQw+l VMWare でいっぱいつんでる http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/616
617: login:Penguin [sage] 2005/06/14(火) 17:45:31 ID:mgJM1oDF よし、物は試しだ。やってみようぜ。 安全のためUSB接続のHDDになると思うけどどのぐらい時間かかるんだろう・・・ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/617
618: login:Penguin [sage] 2005/06/14(火) 20:25:41 ID:4d6wGeMa 男は度胸 なんでもやってみるのさ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/618
619: login:Penguin [sage] 2005/06/14(火) 21:00:07 ID:R4lVrBkP ｶﾈあったらVxFS試したいね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/619
620: login:Penguin [sage] 2005/06/14(火) 23:37:13 ID:a7RV19OY >> レスポンスタイム(16.6ミリ秒) ext2上に4Kのファイルを一つのディレクトリに30万個置いてみました。 ※(creat + write) １ファイル当たり 8.90759 ms $ time for (x=0;x<300000;x++) do cp test.gif /test/$x; done real 44m32.277s user 2m15.260s sys 42m20.050s ※getmeta １ファイル当たり 0.006 ms $ time ls /test | wc 300000 300000 1988897 real 0m1.822s user 0m1.720s sys 0m0.180s ※(open + read) １ファイル当たり 1.14239 ms $ time for (x=0;x<300000;x++) do cat /test/$x > /dev/null ; done real 5m42.717s user 1m48.020s sys 3m19.930s open + read (/dev/nullへのwrite)で、1ファイル当たり1ミリ秒なんだが。。 ちなみにinode不足になるENOSPEのエラーが返ってくるまで 試しましたが、問題ありませんでした。(約160万個) ｉアプリがどうのこうの言ってたので、4年前かな？以下の構成で行いました OS : Red Hat Linux 7.3( kernel 2.4.18 ) CPU : Pentium3 600MHz Memory : 128M disk : Deskstar 75GXP DTLA-307030 30.0G I/Oサイズ : 4096 byte(※iアプリ用だからこのくらいで十分？) ＃改行多いと怒られたので、一部改行削除してます http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/620
621: login:Penguin [sage] 2005/06/15(水) 01:01:42 ID:J8tOFd/9 >>620 ﾊﾔｽｷﾞｽwwwww あそこのblogのシャチョーのマシン、DMAがONになってなかったとかｗ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/621
622: login:Penguin [sage] 2005/06/15(水) 15:05:46 ID:MBJTqnxR しょっぱい人も反応してたけど、そもそもが電波だからなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/622
623: login:Penguin [age] 2005/06/15(水) 20:48:20 ID:xtr7C4EA ext2でマウントされたブロックデバイスAから 同じくext2でマウントされたブロックデバイスBに ファイル(ディレクトリ)をコピーするときに ブロックデバイスAにあるファイルのiノードの情報を ブロックデバイスBにコピーする際に利用することって できますか？？ こうしたらできるはず等ありましたら、教えてください。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/623
624: login:Penguin [sage] 2005/06/15(水) 22:25:46 ID:38oNtCRD iノードの情報ってのがなんなのかよくわからんけど、 ext2ならext2fs.hあたりを利用すればいいんじゃない？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/624
625: login:Penguin [sage] 2005/06/19(日) 13:12:48 ID:/ElOB3AP test http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/625
626: login:Penguin [sage] 2005/06/19(日) 13:59:30 ID:/ElOB3AP OSDL奥山氏の議論にもつながるんだろうが、 ReiserとかExt3とか、ジャーナリングありのFSって、 本当に、「絶対に」整合性を維持できるのだろうか。 たしかに、FSのメタデータの整合性は維持できるかもしれないが、 ジャーナルファイルのメタデータは？ そのデータが含まれるセクタを書き込んでいる最中に電源を落とされたら？ 全自動電源オンオフマシーンとか作って、 ひたすら「コンセント引っこ抜きテスト」を100年間ぐらい続けたとする。 はたして、ファイルシステムの整合性は保たれるだろうか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/626
627: login:Penguin [] 2005/06/19(日) 14:17:08 ID:RuFTTgxb そんなテストになんの意味があるんだかｗ（ﾌﾟｹﾞﾗ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/627
628: login:Penguin [sage] 2005/06/19(日) 14:43:49 ID:ce06SbJt つながんねーよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/628
629: login:Penguin [sage] 2005/06/19(日) 15:48:29 ID:od9dKZxJ >ジャーナルファイルの いかにも奥山のサイトを今朝発見しましたって感じ（ﾌﾟｹﾞﾗ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/629
630: login:Penguin [sage] 2005/06/19(日) 17:08:26 ID:Ax96Dqw8 停電なら不整合は起こるに決まってるジャン。 確実なのはソフト的なアクシデントに対する耐性なんだから。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/630
631: login:Penguin [sage] 2005/06/19(日) 22:47:53 ID:FJdxQCIu 腐ってる vfs 上にのっかてる fs がまともなわけないじゃん. おれは, Linux 客先にだすときはかならず xfs 使う. # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. >>630 > 確実なのはソフト的なアクシデントに対する耐性なんだから。 *BSD の softupdate は, 停電が発生しても, 更新(書き込み)中の ファイルの更新部分が破棄されることはあっても, 更新前のファ イルは生きてるよ. disk が物理的に破壊されれば話はべつだが, 電源段で fs の整合 性が崩れることはない. # background fsck が完了するまでゴミは残ってるけど. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/631
632: login:Penguin [sage] 2005/06/19(日) 22:51:11 ID:FJdxQCIu >>631 echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \ sed 's/もから/もとから/' # ちなみに, 教祖様とは何の関係もないっす. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/632
633: login:Penguin [sage] 2005/06/19(日) 22:58:45 ID:21lYXELW >>631 それはxfsが元のvfsを認めたから他のfsも考慮するってことなのか、 そうなったら腐ったxfsを捨てるってことのどっちなのか？ xfsが提供してるvfsの上に現状のfsをのせるとかすりゃいいのかと思う。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/633
634: login:Penguin [sage] 2005/06/19(日) 23:00:19 ID:rZspg+Mv >>632 >echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \ ^^^^^ たしかに教祖様のレベルにすらいってねーな（ﾌﾟｹﾞ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/634
635: login:Penguin [sage] 2005/06/19(日) 23:35:18 ID:63vKoawi reiser4ってこのまま永久に外様扱いでカーネルツリーに取り込まれないの? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/635
636: login:Penguin [sage] 2005/06/19(日) 23:37:54 ID:5NR2fZUO >>632 それは、sed というファイルにリダイレクトしてるだけのように見える んだが、s/foo/bar/ の意味はあるのか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/636
637: login:Penguin [sage] 2005/06/20(月) 01:37:15 ID:HBmhpWEI zsh: bad pattern: # http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/637
638: login:Penguin [sage ext2も意外に堅いんだよなぁ] 2005/06/20(月) 06:49:59 ID:BNqdYBLn メタデータジャーナルは、停電後の fsck が 短縮される以外の効果は無いと思っても良い。 ジャーナルの無いファイルシステムでも 注意深く実装すれば同等の耐久性が実現できる。 fsck が時間かかることを除けば。 確実に保護できるフルジャーナルは速度が遅すぎて 実用的じゃないので、 UPS を使うことが唯一の解である。きっと。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/638
639: login:Penguin [sage] 2005/06/20(月) 06:53:58 ID:2csWA8Y3 ext2, reiserfsは壊れた事あるけど、 xfsは今のところ壊れてないな。 もちろんデータは飛ぶけど。 ext3に行く前にreiserfsいったから、ext3はわからん。 でも自分が管理してない仕事マシンは全部ext3。 自分が管理してるマシンはext2/xfsだけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/639
640: login:Penguin [sage] 2005/06/20(月) 13:32:04 ID:4sFQXCbB ttp://japan.linux.com/desktop/05/06/20/0123202.shtml で NetBSD の Christos Zoulas が >NetBSDカーネルに感じる主な不満は、以下の点です。 > * ジャーナル・ファイル・システムまたは巨大なファイル・システムのサポートがない。 なんつっとるが、「巨大なファイルシステムサポート」ってのは ファイルサイズがめちゃでかい時のアロケーションストラテジなのか reiserとかxfsみたいなB-Tree系のファイル探索高速化なのか どっちなんやろ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/640
641: login:Penguin [sage] 2005/06/20(月) 16:20:25 ID:7ZDLKH0g NetBSDにはufs2が移植されているのに。 あと、Solarisには大昔からufs loggingがあるから、OpenSolarisからその辺を 持ってこれないもんかな? ってライセンスの問題があるけど。 SolarisといえばZFSってあんまり噂を聞かないなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/641
642: login:Penguin [sage] 2005/06/20(月) 18:16:44 ID:Z94gLUwh ZFSってリリース時には搭載されずアップデートリリースで実装予定とか聞いたけど結局どうなったん WinFSの方も雑誌のインタビューでじっくりと時間をかけてちゃんとしたものを送り出したいとか答えておきながら、 同じ記事内でWinFSはリリースに間に合わないので（略）なんて答えてるし http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/642
643: login:Penguin [sage] 2005/06/20(月) 21:02:54 ID:gLm95Zln solarisのufsで思い出した。 linuxの各種ファイルシステムはCPU（バイトオーダ）に依存しないの？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/643
644: login:Penguin [sage] 2005/06/20(月) 21:35:42 ID:HX5YHyxo >>640 「ファイル・システムの安定性：Linuxにははるかに多くのファイル・システムがあり、 力を入れているファイル・システムがディストリビューションごとに異なる（たいていは 技術的な利点ではなく政治的な理由でそうされる）。ほとんどのディストリビューションは 大きなファイル・システムをサポートし、ジャーナリングが実行される。 残念なことに、一部のファイル・システムは安心して利用できるものではないのだが、 一般のユーザが選択するときの判断材料となるような本当の意味での負荷テストが存在しない。」 って本当に同意。テストすること自体を忌諱しているし、テスト結果をみせつけられると 趣味で作っているOSだからと逃げるし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/644
645: login:Penguin [sage] 2005/06/20(月) 21:38:44 ID:18em1Qe4 >>643 有名なのは大丈夫。 まあそういう悲劇に巻き込まれるのはbigendianと相場が決まっているので、 i386使ってれば心配する必要もなかろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/645
646: login:Penguin [sage] 2005/06/20(月) 22:12:17 ID:zCQQnsES >>644 仕事でファイルシステムに対する要件が厳しければ、 IBMの保守付きでJFSを利用するとか手はあるんじゃない？ 見方にもよるけどLinuxカーネル自体は趣味そのもの。仕方ない。 実際は業務で書いてるコードが大半だけど、そこがまたおもしろい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/646
647: login:Penguin [sage] 2005/06/20(月) 22:25:59 ID:foPz4dSp 64bitで動かないfsもあるぜよ。 JFSは動くようになったんだっけか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/647
648: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/20(月) 23:10:59 ID:BYihUW1Z Solaris10 4/05が6/14に出たが zfsは入ってなかったよ(´･ω･) 128bitファイルシステム。 KMGTPEZY。。。単位はなんだろ。。 詳解ファイルシステムの本書こうかな。 各ファイルシステムの諸元からsystem callの流れ。。 すぐ陳腐化しそうだから毎年出すとか必要だろうな。 大変かも。。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/648
649: login:Penguin [sage] 2005/06/20(月) 23:26:20 ID:7ZDLKH0g >>646 いっそVxFSとか。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/649
650: login:Penguin [sage] 2005/06/20(月) 23:47:15 ID:ks0602uk /.-jp みたいなノリだね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/650
651: login:Penguin [sage] 2005/06/21(火) 01:00:46 ID:b9FBVLlt >>648 よし、頑張れ。 出たら買う。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/651
652: login:Penguin [sage] 2005/06/21(火) 15:18:02 ID:MeWT+wmb >>648 じゃあ洩れも買おう。 FSの基本とかアルゴリズムなど不変な部分は教科書的に書いて、 実践編をこまめに改訂できれば良書になりそう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/652
653: login:Penguin [sage] 2005/06/21(火) 16:30:37 ID:bsn0xczT wiki に 1 日 1 ページ書いていけば？ 報酬ならジャムおじさん方式で。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/653
654: login:Penguin [sage] 2005/06/22(水) 00:31:21 ID:q++h9cos >>643 こんなの見つけた。 やっぱりネットワークバイトオーダーと同じでLittle Endianに してるんだね。 http://www.linux-m68k.org/ext2swap.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/654
655: login:Penguin [sage] 2005/06/22(水) 01:46:41 ID:ffTWYDdq 一応。 ネットワークバイトオーダーはビッグエンディアン。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/655
656: 654 [sage] 2005/06/22(水) 03:38:04 ID:q++h9cos >>655 orz ｻﾝｸｽ。 何言ってんだｵﾚ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/656
657: login:Penguin [sage] 2005/06/22(水) 13:36:08 ID:1+WehZ3c >>620 すぐに試してみる心意気はすばらしいと思うんですが、 ファイルシステムよりforkが律速段階になっている気がする。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/657
658: login:Penguin [sage] 2005/06/22(水) 15:44:46 ID:kPbVU8pP >>635 ttp://lkml.org/lkml/2005/6/21/98 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/658
659: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/22(水) 23:34:50 ID:YmIV6emW 詳解ファイルシステム >>653 wikiでコツコツ作っていきます。(=ﾟωﾟ)ﾉ 本の出版はしたことがない素人なので、 wikiでも良いかなってことで ＃wikiも本格的に触ったことないんで、勉強しながらですけど。。 zfsが秋ぐらいに出るかもしれないので、 そのぐらいまでに形になっていければいいかな？ とりあえず、今日少しだけ書いてみた。 ファイルシステム諸言とvfsについて ファイルシステム諸言は書いてないけどia-64の場合ですので ia-32のほうが利用者多いのでのちほど書きます。 ttp://www.wikihouse.com/linuxfs ＃内容は期待しないでください。。。。 文章考えるのが大変。。 参考文献→linux-2.6.12.tar.bz2 一から作ってるので、オリジナルだと思うけど、どこかに 似た文章があったら教えてください。書き直します。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/659
660: login:Penguin [sage] 2005/06/23(木) 00:23:51 ID:gj5NJeBd おいおい がんばっちゃってよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/660
661: login:Penguin [sage] 2005/06/23(木) 01:10:05 ID:ulPMUhXL 体壊すなよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/661
662: login:Penguin [sage] 2005/06/23(木) 01:23:25 ID:LWBQJQ1j 諸言？諸元？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/662
663: login:Penguin [sage] 2005/06/23(木) 01:42:31 ID:Bb2DfQHA かなり期待。 もしミスや誤字その他で気になることがあっても 追い追いこのスレで話しながら直していけばよいでしょう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/663
664: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/23(木) 01:45:36 ID:cGInpt1v >>662 諸言は誤字です。諸元です。。 直しました。ご指摘ありがとうございますm(__)m vfsについて少し追加(各operations系[fs.h])しました。 ＃絵も一部欠けてたり。。直さなきゃ。。。 ところで、今作ってる「詳解ファイルシステム」って こんな感じで作成し続けて良いのかな？ 細かいところはかなり省いているんだが。。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/664
665: login:Penguin [sage] 2005/06/23(木) 20:45:06 ID:JZIHc1es doxygen した方が早いような http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/665
666: login:Penguin [sage] 2005/06/24(金) 08:11:22 ID:m8AQpDgt 同じ指摘ばかりで申し訳ないですが, 「1ディレクトリに10000ファイルを置くテスト」のように, 10000回touchをforkしていると, 時間の大半はforkに かかってしまい, ファイルシステムのテストにはならない気がします. たとえば, seq 1 10000 | xargs touch だと, 私の環境では, 35倍速くなりました. さらに, 専用の小さなプログラム書けば, もっと速くなって, ファイルシステム自体の速度を見るのに役立つと思います. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/666
667: 666 [sage] 2005/06/24(金) 08:24:18 ID:m8AQpDgt 参考までにforkが1回になるようにやってみました. Cで以下のようなプログラムだと, さらに2倍(元の70倍)でした. int main(int ac, char **av) { char name[10]; int fd,i; if (ac < 2) exit (1); i = atoi(*(av+1)); while (i--) { sprintf (name, "%d", i); fd = creat(name, 00644); close(fd); } } ./a.out 10000 perl だと, seq | xargs と同じくらい. perl -e 'for($i=0;$i<10000;$i++){open $fh, ">$i";close $fh}' xargs がお気楽という点で良いかもしれませんね. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/667
668: login:Penguin [age] 2005/06/24(金) 12:16:38 ID:tsef+KUk 各ファイルシステム間のファイルのコピーってどのように行われているのですか？ パーミッションやファイルサイズ、アクセス時間などをどうやって移動させているかわかりません。 できればkernel2.6、ファイルシステムはext2で具体的に教えてほしいです。お願いします。 参考HP、参考書籍などありましたら、リンクをお願いします。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/668
669: login:Penguin [sage] 2005/06/24(金) 12:37:45 ID:gUOPp5+p GNU fileutilsに含まれるcp(1)のソースを見よ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/669
670: login:Penguin [sage] 2005/06/24(金) 12:39:50 ID:IMmM9dp+ >>668 学校の課題なら自分で調べましょうね http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/670
671: login:Penguin [sage] 2005/06/24(金) 12:56:30 ID:/0PwhOb0 >>659 vfsの絵はreadからすぐにカーネルに入ってもいいような気がする。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/671
672: login:Penguin [sage] 2005/06/24(金) 15:09:06 ID:Ml81310x Reiserﾀﾝ... ｶﾞﾝ( ﾟдﾟ)ｶﾞﾚ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/672
673: login:Penguin [sage] 2005/06/24(金) 20:00:43 ID:tsef+KUk >>669 ありがとうございます。 解決しました。m(_ _)mペコリ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/673
674: login:Penguin [sage] 2005/06/25(土) 04:51:08 ID:lnyqA92V http://www.microsoft.com/japan/msdn/library/ja/jpdnw2k/htm/ntfs2.asp NTFSはsparse fileをサポートしてます。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/674
675: login:Penguin [sage] 2005/06/25(土) 05:15:42 ID:wSJuiDDs 突然何を言うか http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/675
676: login:Penguin [sage] 2005/06/25(土) 10:53:29 ID:8VQiwdit >>675 >>659 の内容についてだと思う。 Linux のカーネルを元に書いてるから、 Windows 関連について不正確な箇所がある。 そこらへんはゆっくり検証していくしかない。 FAT のファイル数制限の検証をしようとしてるけど 遅すぎてまだ終わっていない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/676
677: login:Penguin [sage] 2005/06/25(土) 11:23:05 ID:RIAq5/dk FATは仕様上ルート以外の制限ないんじゃない？ もちろんあるかもしれない実装上の制限を調べたいんなら別だけど。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/677
678: login:Penguin [sage] 2005/06/25(土) 11:45:15 ID:tjGxthTu FATは同一ディレクトリに多数のファイルを置くと 新規作成/削除が目に見えて遅くなるね。 １つ作るのに秒単位で時間がかかる。 もし、ファイルシステム全体での制限を調べているのであれば 今からでも、ディレクトリを細かく分けてテストすることを勧めたい。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/678
679: login:Penguin [sage] 2005/06/25(土) 12:21:46 ID:0zWHwOtL 詳解ファイルシステム？ つttp://www.namesys.com/benchmarks.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/679
680: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/25(土) 12:43:23 ID:WWJmgvXR 指摘をしていただける皆様方ありがとうございますm(_ _)m どんどん反映して良いものに作り上げたいです。 ＃良いものが出来れば、ここのテンプレに載せてもらえるかな(￣ー￣)ﾆﾔﾘ >>666 「1ディレクトリに10000ファイルを置くテスト」 ご指摘ありがとうです。m(_ _)m 1fileをcreateする速度は今のところ 速い 遅い reiserfs > jfs > ext2 > xfs > ext3 > vfat と書いてます。 専用の測定プログラムを書けば、速度は速くなりますが 速いファイルシステム、遅いファイルシステムの順番は変わりますか？ 目的はどのファイルシステムが速いのかを調べることです。 なので、測定プログラム(コマンド)は何でも良いかなと考えております。 1createで何milli secかかるか測定するものではありません。 環境や測定プログラムによってmilli secは変化しすぎるから。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/680
681: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/06/25(土) 12:43:42 ID:WWJmgvXR >> 674 >>676の言うとおり、Linuxのカーネルを元に書いてます。 windows上ではsparse fileをサポートしているが、linuxではまだ サポートしきれておりません。 linux2.6.12.1/fs/ntfs/inode.cの中で、ntfs_truncateで検索してみてると * ntfs_truncate - called when the i_size of an ntfs inode is changed * @vi:inode for which the i_size was changed * * We do not support i_size changes yet. とあるし。 詳解ntfsに記述しておきます。。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/681
682: login:Penguin [sage] 2005/06/25(土) 15:13:48 ID:CMAYG4ue >680 >専用の測定プログラムを書けば、速度は速くなりますが >速いファイルシステム、遅いファイルシステムの順番は変わりますか？ forkなどで律速になったら有意な差が検出できない可能性はある。 またドライバの癖が出る可能性もありそう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/682
683: login:Penguin [sage] 2005/06/25(土) 15:52:43 ID:0zWHwOtL >>680 > 専用の測定プログラムを書けば、速度は速くなりますが > 速いファイルシステム、遅いファイルシステムの順番は変わりますか？ > > 目的はどのファイルシステムが速いのかを調べることです。 > なので、測定プログラム(コマンド)は何でも良いかなと考えております。 > > 1createで何milli secかかるか測定するものではありません。 > 環境や測定プログラムによってmilli secは変化しすぎるから。。 何がしたいのかよく分かりませんな。 君は各ファイルシステムが採用しているデータ構造をサーベイして*ステップ数*で 評価しようとしているのではなかったのか。厳密なステップ数ではなくて計算量オーダーでも別に構わないが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/683
684: 666 [sage] 2005/06/25(土) 16:08:01 ID:/kSYTAkX >>680 元の測定だと99%以上の時間がファイルシステム以外で使われています. 順序を知るのが目的だとして, それら99%分の処理が常に同じ時間で 終えるものであれば, 元の測定方法でも問題ないと思います. ただ, 現実にはforkの時間は結構幅があるような気がします. 後で実際に試してみます. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/684
685: 666 [sage] 2005/06/25(土) 16:14:38 ID:/kSYTAkX > ただ, 現実にはforkの時間は結構幅があるような気がします. > 後で実際に試してみます. やってみました: (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.96s system 101% cpu 11.137 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.02s system 103% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 102% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.39s user 9.97s system 102% cpu 11.041 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 9.99s system 102% cpu 11.034 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.43s user 9.93s system 102% cpu 11.048 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.95s system 102% cpu 11.040 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.97s system 101% cpu 11.140 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 101% cpu 11.150 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.01s system 103% cpu 11.035 total まあ, 無視できる誤差と言っても良いのかなあ… # とはいえ釈然としないものはありますが. http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/685
686: login:Penguin [sage] 2005/06/25(土) 20:51:15 ID:22AYPrE9 >>677 ルート以外もあるよ http://support.microsoft.com/default.aspx?scid=436213 65536 - 2(. & ..)ってとこか http://support.microsoft.com/kb/161982/en Linuxだと-o shortname= で挙動変えてSFN,LFNの場合も変わってくるんでない FAT16 クラスタ数 <= 65526 FAT32 65526 < クラスタ数 < 4177918 1つのクラスタに2つ以上のファイルは入れられないって制限もあるから これも関わってくるか？ ところでvfatって考え的には動的inodeじゃね？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/686
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 297 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.026s