/**ファイルシステム総合スレその7**/

[過去ﾛｸﾞ] /**ファイルシステム総合スレその7**/ (955ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

204: 2007/04/08(日)21:30 ID:IVjfIv3g(2/2) AAS
>>201
サーバとデスクトップで区別する理由が分からん。
どっちでも有用だろ。

手動実行しても重たいとは思わないが、
普通はcronでniceつきで回すだろうから全く問題ない。

>>200
rlocateって標準装備してるdist.ってある?

205(1): 2007/04/08(日)21:50 ID:zsJ2r/Ru(1/2) AAS
ちょっと前にさ、locateが速いのはホントにupdatedbのおかげなのか？と思って

・普通にupdatedb + locate
・単なるfind | gzip > list.gz + zgrep

で比較してみた。

そしたら、なんとfind + zgrepの方が、というかlocateよりも
zgrepでリストファイル検索した方が速かった。リスト作るのも
当然findのみの方が速い。updatedbは内部でデータベース作ってる
わけだけど、スペース削減の意味がほとんどない今、もう過去の
遺物かも知れんと思ったよ。

206: 2007/04/08(日)22:05 ID:EmYGF54Z(1) AAS
過去の遺物だろうね。
fedoraではFC3あたりからlocateのサービスが切られてるよ。
それ以前はデフォルトでcronで走るようになってたけど。

207: 2007/04/08(日)22:08 ID:dD+lSYL+(1) AAS
makewhatisも切ってほしい

208(1): 2007/04/08(日)22:44 ID:tkpoMrl5(1/3) AAS
>>205
なんかオレが調べた結果と違うなあ。(ただしFreeBSD上)

手元のPCはディレクトリとか込みで200万ぐらいファイルがあるんだけど、
zgrepで調べたほうが遅くなる。
アルゴリズム的にファイル数が増えるにしたがって差が開くはず。

locateのデータベースはファイルリストをソートし、一つ前のファイルパスと
異なる部分からしか記録してないのでファイルサイズが小さい。
しかも、検索する際にスキャンするデータの大きさはlocatedbのサイズ分だけ
ですむ。
gzipしたファイルを検索する場合は元のファイルの大きさ分スキャンしないと
省10

209(2): 2007/04/08(日)23:31 ID:HNNwKpZg(2/2) AAS
みんなそんなにファイル調べる事あるの？
>>189
コマンドインストールしてるかなら、パッケージ管理用のコマンド使うし
自分がパスを通している所以外にコマンドが入っていることなんてまず無いし・・・

で、動的なファイル検索ならfindを使う。
色々調べ方を指定できるfindの方が便利だし。

つまり、偶にしか使わない機能だから、ちょっと位速くなっても・・・という気分。

210: 2007/04/08(日)23:39 ID:S1gIGviP(3/3) AAS
>>209
一般ユーザで find / するとパーミッションで読めないファイルあるでしょ。
(これはlocateも同じ問題が発生するが)

わざわざ毎回 find / することを防ぐために locatedb 作ってるんだからさ。
locatedb 更新後に追加したら、updatedb 実行すればいいだけだし。

211(1): 2007/04/08(日)23:43 ID:zsJ2r/Ru(2/2) AAS
>>208
こっちはLinux。規模はやっぱり200万ちょっとくらい。

updatedbのデータはもう作らなくなってしまったので今追試は
できないけど、データ構造的にはupdatedbの方が高速になるはずと
いうのは同意。でも、結果はそうでなかったので「？」だった。
「.」で探して全スキャンとかしてみるとどう？

>>209
大抵のファイルのありかは頭に入っているわけなので、
調べる必要がある時は「わからーん」という状況のことが多い。
そういう時にfindではターンアラウンド大きすぎて試行錯誤できず
省3

212(1): 2007/04/08(日)23:52 ID:tkpoMrl5(2/3) AAS
ソースとか溜め込んでるとlocateは便利だよ。
例えば前にコンパイルしたバージョンほげほげのtarballはどこいったって感じで。

あとconfigureでライブラリとかヘッダーファイルがないって言われたときも結構使うね。
Perlのモジュール使ってるときにも元の.pmファイルが見たいときがあるんで使うなあ。

なんとなくだけど、自分でコンパイルしない人はlocate使わないのかも。

213: 2007/04/08(日)23:58 ID:FgPsXoOH(1) AAS
>>212
findだと大変だもんね。

214(2): 2007/04/08(日)23:59 ID:+N5qr5Yv(3/3) AAS
自分でコンパイルするときはどこに何が置かれるのかおよそ把握するし。
ログを残しておけば、それを見ることも出来るし。
コンパイル専用ユーザとか作るのも普通でしょ？

215: 2007/04/09(月)00:04 ID:tkpoMrl5(3/3) AAS
>>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
省2

216: 2007/04/09(月)00:05 ID:atKY9uJN(1/4) AAS
>>214
小規模かつ一人でやってんならそうでしょうね。

217: 2007/04/09(月)00:06 ID:vrz2OUFg(1) AAS
>>214
tarball内のファイル名全部を記憶してるわけ？
log取ったあとに移したりすると意味無いから、
ログより新しい情報で無いと使えないことがある。

218(1): 2007/04/09(月)00:12 ID:YK4Cy17y(1) AAS
locateは使った時に便利さが実感できるけど
使わない時は本当に使わないね。
半年くらい前にサウンドデバイスのテストしようとして
locate "*wav" したのが最後だ。
cronで毎日更新してるけどなんかもったいないな。

219: 2007/04/09(月)00:15 ID:atKY9uJN(2/4) AAS
>>218
まぁ、いいんじゃない？

220: 2007/04/09(月)00:17 ID:PFZ7GF/k(1/2) AAS
あー、locateバリバリ使わないとどうにもならなかった事例思い出した。

前任者が勝手コンパイルで入れたsenmdmailの入れ替え。
インストールログが一切なくて、そこらじゅうのマシンのいろんなディレクトリに展開されてる
sendmailの内、どれを使ってコンパイルしたのか分からない。
仕方ないからマシン全てでlocateを実行しましたよ。
findだと日が暮れてたと思う。

結局、コンパイルに使ったソースファイルはどこにもなかったけど。

221(1): 2007/04/09(月)00:19 ID:YC9/TDq9(1) AAS
locate 使うかどうかなんて議論するほどのことか?
便利だと思うなら使えばいいし、
必要ないと思うなら使わなきゃいい。
どうしてもやりたいなら雑談スレでやってくれ。

222: 2007/04/09(月)00:23 ID:atKY9uJN(3/4) AAS
>>221
うっせぇよ。どんだけ偉いんだお前？

223(1): 2007/04/09(月)00:41 ID:SYt9P2O4(1) AAS
自分で管理もしてないPCの locate の結果が信用できるのかね。
しかもそんな状態の。

224: 2007/04/09(月)00:45 ID:atKY9uJN(4/4) AAS
>>223
＞自分で管理もしてないPCの locate の結果が信用できるのかね。

言い出したら1日前のファイルリストなんぞなんの信頼性もない。
その正当性は人が確認すればいい話。
何もlocate hoge | xargs rm -rfなんてことがしたいわけじゃないし。
ファイルが今もその辺にあることを「知りたい」だけなんだよ。

225: 2007/04/09(月)00:54 ID:PFZ7GF/k(2/2) AAS
locateの機能をファイルシステム側で提供してくれるとうれしいと思わないかい？

rlocateのやり方だとリモートディスクが変更された場合に検索できなくなるから、
ファイルシステムの機能として取り込んでくれないかなあ。

ぶっちゃけ頓挫したWinFSみたいにDBにメタデータつっこんでくれれば、
なんでもし放題でいいんだけどなあ。

226: 2007/04/09(月)00:56 ID:b08awD+c(1) AAS
beagleとか大して使われなかったな

227: 2007/04/09(月)02:22 ID:EXUr/7hN(1) AAS
単純圧縮だと時間が線形に増えるのに対し、
木検索だとlog2になるので、数が増えれるほど差が開く。

線形検索だと処理が単純な分オーバーヘッドが少ないので、
数が少ない場合は線形の方が速いし、数が多くなれば木の方が速くなるだろ。

更に、パイプでつなげて複数のプロセッサを同時に使えるケースだと単純2倍になるとか、
条件変数をいじれば閾値が変わる。

比較するなら条件付けないと意味なさげ

228: 2007/04/09(月)12:40 ID:jp1FtvCv(1/2) AAS
reiser,reiser騒ぐヤツはどこでも疎まがられてますな。
(Reiser4. BEST FILESYSTEM EVER.)

229: 2007/04/09(月)12:50 ID:F3Ij9AuO(1) AAS
彼らが亡き者にされないことを祈ります

230: 2007/04/09(月)13:34 ID:jp1FtvCv(2/2) AAS
>REISER4 FOR INCLUSION IN THE LINUX KERNEL.
危な臭くなってきますた。

231: 2007/04/09(月)13:53 ID:72H5EoZf(1) AAS
どこに書かれていますか

232: 2007/04/09(月)14:06 ID:2R5UgYQX(1) AAS
Reiserの事件が起きたのが不思議だったが
このスレの速度見てたら納得した。

Linuxに於いてファイルシステムは重要な位置にある。

Reiser裁判の続報マダー？

233: 2007/04/09(月)15:53 ID:jlcenkeg(1) AAS
SCO裁判と合流いたします。

234: ◆IIiDC8JS7w 2007/04/10(火)01:12 ID:7nQI0l/r(1) AAS
4/6からreiser4のお話でLKMLが荒れてます。
お話はベンチマークでreiser4最強説から始まる。。。

BEST FILESYSTEM EVER.
外部ﾘﾝｸ:marc.info
外部ﾘﾝｸ:marc.info

REISER4 FOR INCLUSION IN THE LINUX KERNEL.
外部ﾘﾝｸ:marc.info

Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE
外部ﾘﾝｸ:marc.info

235(1): 2007/04/10(火)09:09 ID:TLRAIA8b(1) AAS
mmカーネルには入ってるのだから、
メインストリームに入れられない理由が技術的問題なんてありえない。

236: 2007/04/10(火)17:24 ID:SKiObrIB(1/2) AAS
>>235
ここまで大きくなると、政治も技術なんだよね。

237: 2007/04/10(火)17:35 ID:NbCL9/FB(1) AAS
単にコミュニケーション能力だろ？

238(1): 2007/04/10(火)18:39 ID:72LWlPWO(1) AAS
メインストリームに入れたとして誰がメンテナになるの？
一緒に変更されるIO周りのメンテナンスは？
入れて終わり、じゃないから難しい

239(1): 2007/04/10(火)22:20 ID:WYQ/GLOl(1) AAS
>>238
俺だけど？

240: 2007/04/10(火)22:51 ID:SKiObrIB(2/2) AAS
>>239
お前じゃぁ、やっぱり見込み無いな・・・。

241: 2007/04/10(火)23:22 ID:epWNgzd4(1) AAS
akpmなら、akpmならやってくれる！！

242(1): 2007/04/10(火)23:45 ID:meYFnXcY(1) AAS
mm＝マジムカツク

243: 2007/04/11(水)01:12 ID:OGV1dpwn(1/2) AAS
>>242
-mm は、マゾ・マニア用。

244(2): 2007/04/11(水)01:28 ID:SCjN+X9I(1) AAS
Reiser4の最強性能を使いたくないとは
判り易すぎる工作員だよな。

きなくさいどころか大炎上ものだろ。
反対するやつら尋問して黒幕吐かせろよ。

245(1): 2007/04/11(水)02:36 ID:veJPWDy0(1) AAS
>>244
ちょいと聞きますが「Reiser4の最強性能」って具体的にどんなもんですか
新規インストールするノートPCにどのFS使おうか迷ってるもので参考の為お伺いします

246: 2007/04/11(水)06:27 ID:JLZuygxe(1/2) AAS
とりあえずチキンな俺は ext3 だな。

247: 2007/04/11(水)06:27 ID:OGV1dpwn(2/2) AAS
>>244
ここで工作活動して、なんの意味が・・・?
皆ext3のダメなところを十分知ってて使ってるだろうよ。

248: 2007/04/11(水)07:49 ID:JLZuygxe(2/2) AAS
jfsはチキンな俺でも時々使ってる

249: 2007/04/11(水)11:26 ID:sDZCnxJd(1/2) AAS
ルートはext3だがデータフォルダはjfsだぜ。
特にいいところも問題もないから話題にならなくて困る＝情報が少ない。

250(1): 2007/04/11(水)16:38 ID:jrv4Ve51(1) AAS
ﾗｲｻﾞｰをﾊﾞﾆﾗに入れるとだれもext*を使わなくなるから。

251: 2007/04/11(水)17:31 ID:nWq7Sr57(1) AAS
>>250

ディストリビューションが公式にサポートしない限り、バニラカーネルに入っても
あまり使われないような気がする

252: 2007/04/11(水)18:24 ID:qZdt7s1O(1/3) AAS
ディスク使用効率を比べたらJFSが一番良かったので動画保存用に使ってる。
NFSサーバにもしてるが性能は気にならない。
SquidのキャッシュはXFS。
データベースもXFS。
この二つは以前reiserfsだったが、システムが不安定になったのでやめた。
その他はext3で何ら問題ない。reiserfs以外はクラッシュした事も無い。

253: 2007/04/11(水)18:25 ID:qZdt7s1O(2/3) AAS
FTPサーバがまだreiserfsだった。
そういやこいつも何ヶ月に一度か固まるんだよなぁ。
reiserfsやめようかな。

254: 2007/04/11(水)18:30 ID:Bbr4qd52(1) AAS
FreeBSD 7が出たら、ファイルサーバはLinux ext3からFreeBSD ZFSに移行する予定。
OpenSolaris ZFSのほうがいいんだけど、ヲレはいいにせよ、いつか管理を引き継ぐときに
後任の人間が管理できなさそうなので。

255: 2007/04/11(水)18:47 ID:qZdt7s1O(3/3) AAS
それは勇者だな。止めはせぬ。止めはせぬぞぉ。

256: 2007/04/11(水)18:48 ID:sDZCnxJd(2/2) AAS
smpatch update叩いて
svcadmin 叩くだけでいいんじゃないっすか？

FreeBSDもSolarisもLinuxしか知らない人間にとったら同じなのでは？

257: 2007/04/11(水)21:54 ID:XAfrtCFB(1) AAS
そういう意味じゃないだろ

258(1): 2007/04/12(木)01:32 ID:XK3lSsMk(1) AAS
Sun、次世代ファイルシステム「ZFS」の技術をOpenSolarisへ寄贈
外部ﾘﾝｸ[html]:journal.mycom.co.jp

これでLinuxへの移植も弾みが付くかな？

259: 2007/04/12(木)01:48 ID:Doi0XtNY(1) AAS
>>258
VFS (ぼそっ)

260: 2007/04/12(木)03:32 ID:3iq35grF(1) AAS
GPLか、となると、もう、ごそっと根こそぎ色々買えちゃいましょうよ。

・・・いや、それならSolarisカーネル使ったほうが早いか・・・

261: 2007/04/12(木)08:50 ID:K4BKMimV(1) AAS
じゃあGNU/Solarisで握ってください

262(2): 2007/04/12(木)10:02 ID:8G0xdNdm(1/3) AAS
結局VFSの何が問題か誰も説明できてないんだよね。

263: 2007/04/12(木)10:26 ID:rYnLamFa(1/2) AAS
説明できるくらいならなおせるからでしょ。
一言でいうなら｢遅い=効率悪い｣ってことじゃ？

264: 2007/04/12(木)10:32 ID:f7nO3IV0(1) AAS
>>262
煽る以外に芸のない、いつもの人乙。まあ、恥垢臭全開の悪臭公害っぷりは
芸に入るのかもしれないけどな。

265: 2007/04/12(木)10:44 ID:0cfLNdmr(1/5) AAS
遅い？
なにが？

266(2): 2007/04/12(木)10:45 ID:4Cg0BFlt(1) AAS
エラーを伝えて上流の処理を変える機構が無い　んじゃ？
エラーといってもリトライでどうにかなるものもあれば、別のセクタに再割り当てしなきゃならないものもあるし、
FS内の格納情報まで遡って変更をしなければならないものもあるだろう。

Ｃ言語が「戻り値を複数持つように設計されていない」のと同じで、設計から抜け落ちているんだと思うが。

SCSIは、それに対する解決法の一つとして、まずエラーが発生した事を伝え、
詳細情報は別途参照するようになってるけどな。

267: 2007/04/12(木)10:46 ID:bNSAwxSf(1/5) AAS
>>262
そういえば、ソースコードで指摘してるのいないな

268: 2007/04/12(木)11:08 ID:8G0xdNdm(2/3) AAS
>>266
そんな抽象論をされても困るのですが。

269: 2007/04/12(木)11:20 ID:yLg5Zjmp(1) AAS
抽象論でも具体的に反論できる人ならできる話に見えるけど。
それができずにVFSが駄目という定説を覆そうなんて思ってるの?

270: 2007/04/12(木)11:24 ID:8G0xdNdm(3/3) AAS
じゃ、libataのFUAとかDPOのサポート状況を見れとかそういう話をすればいいのかな？
>>266はATAとSCSIの一般論をいっているような気がするので。

271: 2007/04/12(木)11:25 ID:QideTFxj(1/2) AAS
>>ID:8G0xdNdm
こいつを相手にするだけ無駄だって

272: 2007/04/12(木)11:35 ID:0cfLNdmr(2/5) AAS
ソースコードの指摘まだ出てこないですねえ
ソースコード指摘したら、相手してやってもいいけどなあ

273: 2007/04/12(木)11:36 ID:i6Q8o8tQ(1/2) AAS
ソースが欲しいんだって

274(1): 2007/04/12(木)11:37 ID:bNSAwxSf(2/5) AAS
このスレにそんな高等なやつおらへん
ソースコード、gitでとってきて読んでるやつすらいないと思われる

275: 2007/04/12(木)11:51 ID:0cfLNdmr(3/5) AAS
>>274
そうなの？ちょと幻滅
簡単なんだけどなあ
でも、俺のカーネルレポジトリのディレクトリに移動したから、もうちょっと待ってみる

276: 2007/04/12(木)11:55 ID:bNSAwxSf(3/5) AAS
gitの使いかたすら知らない奴がいたりしてw

277: 2007/04/12(木)12:47 ID:rYnLamFa(2/2) AAS
知りません教えてください
でもそういう技術的なことと設計の問題は別ではないのですか

278: 2007/04/12(木)12:53 ID:+nm2g3SB(1/2) AAS
git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
とか。
さあ語れ。

279: 2007/04/12(木)12:54 ID:bNSAwxSf(4/5) AAS
えーと、ソース落としたことない奴いるのかよw

280: 2007/04/12(木)12:58 ID:i6Q8o8tQ(2/2) AAS
ソースを落とすのがそんなに高等なことですか

281: 2007/04/12(木)13:08 ID:bNSAwxSf(5/5) AAS
じゃねえw
ソース落としたからには、読むってことはするんだろうしw

282: 2007/04/12(木)13:09 ID:0cfLNdmr(4/5) AAS
みんな逃げちゃったの？
暇だから、linux-2.6/fs配下適当に読んでる

283: 2007/04/12(木)13:11 ID:QideTFxj(2/2) AAS
暇なら働けばいいじゃん

284: 2007/04/12(木)13:12 ID:0cfLNdmr(5/5) AAS
OpenBSDがぱくったソースでも見るかな

285: 2007/04/12(木)14:53 ID:HfAttzGM(1) AAS
なんの技術論もせずに煽るだけ煽って消えたか。さすがはいつもの人。

286(1): 2007/04/12(木)17:41 ID:nVM4eCBE(1/2) AAS
git使いがいるっぽいのでスレ違いだが質問
ファイルのタイムスタンプそのままでcloneするにはどうすればいいのん？

287(1): 2007/04/12(木)18:08 ID:+nm2g3SB(2/2) AAS
>>286
gitレポジトリにはタイムスタンプ情報は無い気がする。

288: 2007/04/12(木)18:28 ID:nVM4eCBE(2/2) AAS
>>287
あんがとう

man読んでも見当たらなかったと思ったら、やっぱりそうなのかー
その点は好きになれんなー

289: 245 2007/04/12(木)20:09 ID:iBsZ/gGJ(1) AAS
>>245 です
アク禁で今まで書けませんでしたが、皆さんありがとうございました
ところで昔々言われてたJFSの日本語問題ってどうなったんでしょう?
(クグったんてすが解決したという完全な記述が見付からなかった)
あとSELinux使うにあたってはJFSやReiser4でも問題なさそうなので良かったです

290: 2007/04/13(金)01:15 ID:hoo6qTbR(1/3) AAS
漏れ、XFSの性能がいい理由とVFSがダメっつー話が実際のところコード的に
何が違うのか知りたくてコード追っかけたことある。ところが、ext*だろうが
XFSだろうが、結局カーネルの共通ルーチンに途中で処理が委譲されていってしまい、
結局なんであんなにXFSがいい結果を出せるのか正直理解できなかった。
その過程に何かあるんだろうけど。

シンポジウムでmmがext4に関連して「ext4設計するためにXFSが
あれだけいいのはなぜか、時間ができる度にソースを読むのだが、
わからない」と話したそうでログがxfs-mlに出てたけど、レベルは
違うだろうがまさにそんな感じ。

ただ、XFS on Linuxのソフトウェア的な構造は他のfsとは異質で、
省4

291: 2007/04/13(金)01:21 ID:hoo6qTbR(2/3) AAS
s/mm/akpm/

292: 2007/04/13(金)10:42 ID:hzqk3K7N(1/2) AAS
ロリコン

293(1): 2007/04/13(金)15:21 ID:ZgJh2Ld8(1) AAS
XFSがそんなに速いなんてしらなかった。
マウントが妙に速いとは思っていたけど、使ってみて速さを特には感じなかったから。
ちょっと見直そうかな

294: 2007/04/13(金)16:31 ID:kwlQ/nE+(1) AAS
実際に製品で使われているものだから
sgiも気合い入れてるんでしょ

ところでJFSて製品で使われてるの？
IBMの

295: 2007/04/13(金)19:15 ID:hzqk3K7N(2/2) AAS
AIXだとデフォルトでjfsじゃ無かったっけ？

296(2): 2007/04/13(金)22:00 ID:hoo6qTbR(3/3) AAS
>>293
速くはないよ。遅くもないけど。
重く（なら）ないというのがより正確だと思う。

速度だけなら揉めてる最中のreiser4が侮れない。「お前ホントに
書いてるのか」と思うくらいブッチギリの時がある。ちなみにJFSが亀。
あまりにも差が付いてるので再測定してる所だけどな。

ただ、読み書きサイズを増やすと優劣の順位はしっかりあるものの、
数割の範囲内に収まってくるので、通常利用（＝小ファイル
アクセスで体感しているもの）は結局はバッファリング性能とか
ディレクトリエントリのスキャン性能を体感しているだけと
省1

297(2): 2007/04/13(金)22:11 ID:wAI/O+K+(1) AAS
>>296
reiser4はベンチ上での速度？
圧縮してるから、ベンチとかでよく使うファイルは0ばっかのファイルで
書き込み量も少なくなるし、速くなるのは道理、とか言ってたな。

298(1): 2007/04/13(金)23:20 ID:vMxS3Vxb(1) AAS
>>296
> 「お前ホントに書いてるのか」と思うくらいブッチギリの時がある。

cacheに書いてACK返しているとかいうオチは無いよな?

299: 2007/04/13(金)23:48 ID:cwoFeYOd(1) AAS
>cacheに書いてACK返しているとかいうオチは無いよな?
XFSもそうだ。

300: 2007/04/14(土)00:45 ID:nAecf1s7(1/4) AAS
>>298
そういう状態も含めて各種条件でデータ取ってます。結局実使用条件は
様々なので、全部デフォルト、sync、O_SYNC、stdio使う、syscall直、
ログサイズ、コミット間隔など、mkfs/mount/benchmark方法の３条件を
パラメータとして変えていってfsによってどう挙動が変わるかなと。
組み合わせ爆発が起きるのでかなり絞ってるんですが、１巡させるだけで
１週間とか、馬鹿みたいに時間かかってます。

>>297
です。postmarkでやってます。これはランダムデータ書くので、
たぶんバッファリングと小ファイルの持ち方が強烈に効いたのかなと推測。

301(1): 2007/04/14(土)00:58 ID:+AesjW7P(1) AAS
>>297
圧縮の意味まちがえてるんだぜ?

302: 2007/04/14(土)06:08 ID:OZ+7/Bvj(1) AAS
winから読める、winを読む、の互換性重視で言ったらまだext3のほうがいいの？

303: 2007/04/14(土)07:37 ID:W+0IctxX(1/3) AAS
ｻﾝﾊﾞつかえばFSは何でもよいのでは？

上下前次 1-新書関写板覧索設栞歴

あと 652 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.038s