[過去ログ] /**ファイルシステム総合スレ その3**/ (983レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
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ビット機の昔から、ゲームで大量に使わなきゃいけないデータは単純に結合した1つのファイル
にでもしておく手法が主流だったんじゃないか?
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
デスクトップでは、まだ1Gでしょ。
熱心な人が2〜4Gにするくらいで。
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) 1ファイル当たり 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 1ファイル当たり 0.006 ms
$ time ls /test | wc
300000 300000 1988897
real 0m1.822s user 0m1.720s sys 0m0.180s
※(open + read) 1ファイル当たり 1.14239 ms
省12
621: 2005/06/15(水)01:01 ID:J8tOFd/9(1) AAS
>>620
ハヤスギスwwwww
あそこのblogのシャチョーのマシン、DMAがONになってなかったとかw
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
そんなテストになんの意味があるんだかw(プゲラ
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は同一ディレクトリに多数のファイルを置くと
新規作成/削除が目に見えて遅くなるね。
1つ作るのに秒単位で時間がかかる。
もし、ファイルシステム全体での制限を調べているのであれば
今からでも、ディレクトリを細かく分けてテストすることを勧めたい。
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
684: 666 2005/06/25(土)16:08 ID:/kSYTAkX(1/2) AAS
>>680
元の測定だと99%以上の時間がファイルシステム以外で使われています.
順序を知るのが目的だとして, それら99%分の処理が常に同じ時間で
終えるものであれば, 元の測定方法でも問題ないと思います.
ただ, 現実にはforkの時間は結構幅があるような気がします.
後で実際に試してみます.
685: 666 2005/06/25(土)16:14 ID:/kSYTAkX(2/2) AAS
> ただ, 現実には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
省5
686(3): 2005/06/25(土)20:51 ID:22AYPrE9(1) AAS
>>677
ルート以外もあるよ
外部リンク[aspx]:support.microsoft.com
65536 - 2(. & ..)ってとこか
外部リンク:support.microsoft.com
Linuxだと-o shortname= で挙動変えてSFN,LFNの場合も変わってくるんでない
FAT16 クラスタ数 <= 65526
FAT32 65526 < クラスタ数 < 4177918
1つのクラスタに2つ以上のファイルは入れられないって制限もあるから
これも関わってくるか?
省1
687: 2005/06/25(土)21:11 ID:onicx32O(1) AAS
users-jp(・∀・)ニヤニヤ
688(1): 2005/06/26(日)03:31 ID:ykvfdS2d(1) AAS
>>686
>Windows では、長いファイル名、サブディレクトリ名、8.3 に短縮された
>エイリアス毎に、それぞれディレクトリ エントリを使用します。
だから結局その半分。
昔1フォルダに3万強以上でファイルが作れなくなったことがあって「仕様と違う」
と思ってたことがあったのだが、これで理由がわかった。
689(1): 2005/06/26(日)03:55 ID:VMpc2wjm(1) AAS
よーく考えろ。作れる数に制限ないとFATの容量(メタデータ)が決まらないだろう。
690: 2005/06/26(日)09:50 ID:GiQyR/FG(1/3) AAS
>>689
FAT の容量はパーティションの容量とクラスタサイズで決まったはず。
ファイル数等の制限とは直接は関係は無かったはず。
1つのクラスタに1つまでのファイルしか入らないので、
その意味でファイル数が制限されることはある。
メタデータは FAT とは別に存在して一応柔軟に生成できる。
但しオンラインデフラグでは移動や削除はできない。
691: 2005/06/26(日)11:34 ID:GiQyR/FG(2/3) AAS
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){
省8
692(1): 2005/06/26(日)17:14 ID:oC8YKbwx(1/4) AAS
FAT16 と FAT32 の違いって、なぁに?
693(1): 2005/06/26(日)17:47 ID:GiQyR/FG(3/3) AAS
>>692
少し上に答えはあるぜ >>686
ついでに途中経過、42万のフォルダを生成できた。
この調子だと容量を使い切るまで作れそうだ。
上下前次1-新書関写板覧索設栞歴
あと 290 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.035s