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