[過去ﾛｸﾞ]
/**ファイルシステム総合スレ その3**/ (983ﾚｽ)
/**ファイルシステム総合スレ その3**/ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
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
687: login:Penguin [sage] 2005/06/25(土) 21:11:55 ID:onicx32O users-jp(・∀・)ﾆﾔﾆﾔ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/687
688: login:Penguin [sage] 2005/06/26(日) 03:31:07 ID:ykvfdS2d >>686 ＞Windows では、長いファイル名、サブディレクトリ名、8.3 に短縮された ＞エイリアス毎に、それぞれディレクトリ エントリを使用します。 だから結局その半分。 昔1フォルダに3万強以上でファイルが作れなくなったことがあって「仕様と違う」 と思ってたことがあったのだが、これで理由がわかった。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/688
689: login:Penguin [sage] 2005/06/26(日) 03:55:13 ID:VMpc2wjm よーく考えろ。作れる数に制限ないとFATの容量(メタデータ)が決まらないだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/689
690: login:Penguin [sage] 2005/06/26(日) 09:50:02 ID:GiQyR/FG >>689 FAT の容量はパーティションの容量とクラスタサイズで決まったはず。 ファイル数等の制限とは直接は関係は無かったはず。 １つのクラスタに１つまでのファイルしか入らないので、 その意味でファイル数が制限されることはある。 メタデータは FAT とは別に存在して一応柔軟に生成できる。 但しオンラインデフラグでは移動や削除はできない。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/690
691: login:Penguin [sage] 2005/06/26(日) 11:34:54 ID:GiQyR/FG my $cow = 1; while($cow < 65536*256){ my $we = ""; my $sd = $cow; while($sd > 0){ $we = "\\".($sd & 7).$we; $sd >>= 3; }; $we = "H:".$we; if(mkdir($we) == 0){ exit(); }; print($we."\t(".$cow.")\n"); #sleep(1); $cow++; }; こんなプログラム（Win用）で FAT32 上でフォルダ（ディレクトリ）を階層構造で作って見た。 DVD-RAM でテスト中、現在、８万以上のフォルダ生成に成功、速度低下も余りなし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/691
692: login:Penguin [sage] 2005/06/26(日) 17:14:47 ID:oC8YKbwx FAT16 と FAT32 の違いって、なぁに？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/692
693: login:Penguin [sage] 2005/06/26(日) 17:47:34 ID:GiQyR/FG >>692 少し上に答えはあるぜ >>686 ついでに途中経過、４２万のフォルダを生成できた。 この調子だと容量を使い切るまで作れそうだ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/693
694: login:Penguin [sage] 2005/06/26(日) 18:12:14 ID:oC8YKbwx >>693 構造の違いについては記載されてないわけだが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/694
695: login:Penguin [sage] 2005/06/26(日) 18:21:53 ID:mVauA+98 >>688 長いファイル名が長いと、1つのエントリでは納まらないのでさらに減ります。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/695
696: login:Penguin [sage] 2005/06/26(日) 18:25:26 ID:oC8YKbwx /usr/src/linux/include/linux/msdos_fs.h にある構造体とかか。 msdos_dir_entry msdos_dir_slot Windows95 になったとき、それまでの MS-DOS ようのプログラムが、 msdos_dir_slot を適正に処理できなくて、うんこな状態だった話とか そんな昔話してもいい？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/696
697: login:Penguin [sage] 2005/06/26(日) 18:32:18 ID:i4XLxkmZ そういえば、FAT系って ・ルートディレクトリのエントリ数の制限(FAT32でルート移動可になって解消だっけ？) ・システム内ファイル数の制限(クラスタ数の制限だっけ？) があった気がするけど、 ファイル数の制限には、「サイズ０のファイル以外で」という条件があったはず。 つまり、サイズ０のファイル(ディレクトリエントリのみ)は 容量が許す限り、幾つでも作れたはず。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/697
698: login:Penguin [sage] 2005/06/26(日) 18:34:46 ID:oC8YKbwx つーことは、EOF_FAT を書くから消費されないということでつかね。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/698
699: login:Penguin [sage] 2005/06/26(日) 20:29:30 ID:53gDFny3 メタデータを使わないファイルシステムって 代表的な奴は何になるのかな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/699
700: login:Penguin [sage] 2005/06/27(月) 00:17:39 ID:XIAnMrHa >>686 にあるようなディレクトリごとのファイル数制限について。 ttp://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx ルートディレクトリのファイル数制限は FAT12・FAT16 の制限で一般に 512 まで だけど、フォーマット時に決められる様で 65535 まで増やせそうだ。 サブディレクトリや FAT32 のルートディレクトリのファイル数制限は FAT の仕様ではなく Win98 系の実装上の制限が原因の様だ。 Win2000 系においても互換性のためにあえて制限しているようだ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/700
701: login:Penguin [sage] 2005/06/27(月) 00:22:44 ID:NSUS6+Q8 マウントの概念がなかった時代に関しては、ルートディレクトリに たくさんファイルをおける必要はないもんなぁ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/701
702: login:Penguin [sage] 2005/06/27(月) 12:41:25 ID:pXBFKh0E >>701 FDの時代だ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/702
703: login:Penguin [sage] 2005/06/27(月) 12:48:58 ID:p4DBj9q6 >>701 今更ながらすげー納得した http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/703
704: login:Penguin [sage] 2005/06/27(月) 14:21:45 ID:Dj69fw9T >>702 1Dなら160kb http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/704
705: login:Penguin [sage] 2005/06/27(月) 20:39:32 ID:Zr371K4o 階層ディレクトリの無い時代にも同じ制限があって、困っちゃったわけだが。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/705
706: login:Penguin [sage] 2005/06/27(月) 22:54:14 ID:XTzwjHSw 他のfsの歴史はちゃんと1.0公開とかあるのに 1997年6月23日 reiserfs のソースコードを web に置く ってのがﾜﾛﾀ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/706
707: login:Penguin [sage] 2005/06/28(火) 05:41:49 ID:VwXWpqIZ >>699 ファイルサイズもメタデータなので メタを持にないFSで代表的なのは まずはテープデバイスだろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/707
708: login:Penguin [sage] 2005/06/28(火) 06:52:53 ID:Si6gc8X+ 漢直ユーザですか？ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/708
709: login:Penguin [sage] 2005/07/09(土) 21:57:47 ID:Ubb0Ca9l wikihouse重杉 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/709
710: RHEL4デバッグ係り ◆IIiDC8JS7w [sage] 2005/07/10(日) 00:38:42 ID:cUIiVWkd wikihouse重杉 ということで7/7 wiki.livedoor が出来たのでミラー作成 ttp://wiki.livedoor.jp/linuxfs ソースをコピーしただけだから若干表が崩れてます。 ＃livedoorは手動ミラーなので更新遅いかも。。 vfsをとりあえず、完成させてから ext2,nfs,reiserfsの説明を充実していきます。 vfs部分はgoogleで調べても載ってないものが多いから ソース調べて書いてるけど、間違いあったら指摘 よろしくお願いしますm(_ _)m いろいろ書きたい。。(*´Д`) kernel2.6.13のこととか脱線気味もたまにはあるけど 気長に完成目指してがんばるっすよ http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/710
711: login:Penguin [sage] 2005/07/10(日) 00:50:22 ID:kqrF/M/5 >>710 乙。 > kernel2.6.13のこととか脱線気味もたまにはあるけど むしろそれが面白い。 雑誌だとコラムとかに面白いネタ転がってたりするし。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/711
712: login:Penguin [sage] 2005/07/10(日) 01:38:32 ID:ZmoKp9tD >>710 おまけのところ s/XIM/XIP/ ramdiskなんかに置いてある実行ファイルを そのまま実行してしまうという技でつ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/712
713: login:Penguin [sage] 2005/07/15(金) 20:17:59 ID:U9SD/WLG ttp://www-6.ibm.com/jp/developerworks/linux/050715/j_os-openafs.html OpenAFSって使ったことある方いますか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/713
714: login:Penguin [sage] 2005/07/15(金) 23:55:01 ID:2mmQ3FNZ @it にて、 ttp://www.atmarkit.co.jp/flinux/rensai/linuxtips/763fsflag.html の、記事を読む。 今まで、「Linuxでデフラグは、いりません。」と、読んだ本に書いてあったので、 「どういう仕組なんだろう。」と、不思議に思いつつも信じていた。 のに。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/714
715: login:Penguin [sage] 2005/07/16(土) 00:29:55 ID:XZff9mlB フラグメント化した状態は示されても、 フラグメント化したディスクへのアクセスがどれくらいパフォーマンスを劣化させるかは示されていないのだが、 それでよいのか? http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/715
716: login:Penguin [sage] 2005/07/16(土) 00:31:56 ID:TrDZO+rB なんか /bin/bash あたりがフラグメントしてるのを見て鬱になったぼくがきましたよ。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/716
717: login:Penguin [sage] 2005/07/16(土) 00:40:12 ID:/wbHtX7A /bin/sh -> /bin/bash な環境なら確実にキャッシュに入ってるだろうし、 そうでなければ逆にまったく問題ないであろう。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/717
718: login:Penguin [sage] 2005/07/16(土) 01:50:23 ID:OEvkVj9m >715 ttp://lc.linux.or.jp/lc2005/01.html http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/718
719: login:Penguin [sage] 2005/07/16(土) 03:07:26 ID:XZff9mlB >>718 それ中身を良く読むと、 ・ iozoneを複数個並列に動かすような、実環境でありえない方法で激しいフラグメント化を起こし ・ にも関わらず、CPU占有時間は変化せず(スループットは低下せず) ・ シングルスレッドのパフォーマンスの低下も1/2程度 となってて、結局のところ 「実環境でext3fsのフラグメント化の影響を心配する必要はありません」というデータに 見えるのは、私だけかな。 http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/719
720: login:Penguin [sage] 2005/07/21(木) 23:07:52 ID:DRSMPsxh > うはっｗ俺Al Viroのpatchみてねーや リーナスあたり言ってそうだな http://hayabusa6.5ch.io/test/read.cgi/linux/1101495293/720
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 263 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.026s