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

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

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

553(1): 2005/06/06(月)06:18 ID:s8RLPHSC(1) AAS
あくまで、fsに関してのセンスが最悪なLinus的に素晴らしいパッチだけどな。

554: 2005/06/06(月)07:40 ID:SMFVEdZT(1) AAS
reiserはサイズの小さいファイルに適していると聞くけど、具体的にどれくらいのサイズまで適してるの?

555: 2005/06/06(月)14:13 ID:wuoAwrG5(1) AAS
>>550
コーヒー噴いた

556: 2005/06/06(月)15:32 ID:D/IOdsga(1) AAS
>>553
素晴らしくないから拒否される。
本当に最悪と思うなら、>>553の言う最高にセンスのある fs に書き直してみせろよ。

557: 2005/06/06(月)16:22 ID:poq1WMUj(1) AAS
Qu Fupingはfs/mpage.c(MLではmmap()の話だったような)について
同じ動機(デバイスのI/O error対処がなってない)でパッチを投稿して、
Mortonに査読されて、昨日Linusにとりこまれたみたいね。
外部ﾘﾝｸ:grmso.net:8090

とりあえず、Qu Fupingにとっての第一段階の到達点はfsのセンスがどーのこーのではなく、
存在しなくなったデバイスへの書き込みは揃ってEIOを返せというあたりだろうから、
小出しにパッチ書いて投稿できるんじゃないかな。

558(2): 2005/06/06(月)23:42 ID:yGEbpLlG(1) AAS
reiserfsはpageサイズ以内であれば速いですね。
i386なら4Kbyte以内、x86_64とia64であれば16Kbyte以内

reiserfs_file_write
や
reiserfs_writepage
->reiserfs_write_full_page

のソースを追っていけばわかるが、書き込み領域が
1ページの場合だけ、特殊な動作でwrite処理を実現している。
特殊な動作ってのは説明しづらいが。。
小さいファイルをページに詰める処理があって、seekの負担を
省7

559: 2005/06/07(火)00:44 ID:rKiW1npn(1) AAS
>>558
詳解ファイルシステムとか出して
買うよ

560: 2005/06/07(火)01:03 ID:dZKu4NWQ(1) AAS
>>558
洩れも買うぞ。
reiser4もよろ。

561: 2005/06/07(火)01:04 ID:bb9xKaSm(1) AAS
解説書の陳腐化速度予想

低速高速
<--------------------------->
UFS JFS XFS EXT2 EXT3 ReiserFS(測定不能)

562: 2005/06/07(火)13:45 ID:lZfPWDIo(1) AAS
工夫はいろいろされていると思うが、小細工がかえってパフォーマンスを悪化させることもあって、
実際にどのサイズでどの程度速いかは測らないとわからないかもしれず。

563(1): 2005/06/07(火)17:12 ID:CL2BJbX6(1) AAS
>>539
ぶっちゃけた話、↓これに尽きるだろ。
2chｽﾚ:linux
>Kyle> But you miss the point. Linux is *NOT* about "business", or "enterprise", or "mission-critical". Linux is (at least to many hackers) about hacking, having fun, and Good Design(TM).

564: 2005/06/07(火)21:16 ID:g668WLL2(1) AAS
reiserfs4の内部構造の解説はどこかにwikiがあったよ

565: 2005/06/07(火)21:50 ID:bGOaxwoO(1) AAS
>>563
そのレスの中で一番ウケたのは
Andi> Didnt review more.
だなｗｗｗｗｗｗｗｗｗ

566(1): 2005/06/08(水)01:18 ID:hmEOGUL7(1/2) AAS
ReiserFS のパッキングは確かに速度低下の原因になっているよ。
だから Reiser4 では改良の対象になっている。
ただ、他の工夫で速度をあげているけど。

>>532 にあるような、NTFS XFS の方法は
効果は極端に小さいファイルに限定される。
（NTFS の場合、約 700バイト以下）
ReiserFS の場合、中途半端に小さいファイルでも効果あり。

Reiser4 がなかなか登場しないからいっそのこと
ReiserFS (v3) で / を作る手を打つべきだろうか。
速度にこだわらないなら ext2 も意外に堅牢だと言うし迷うな。

567(1): 2005/06/08(水)01:52 ID:xSWyctMC(1) AAS
>>566
Reiser4が登場しないってどゆこと？

568: 2005/06/08(水)02:02 ID:hmEOGUL7(2/2) AAS
>>567
書き方悪かった。

標準カーネルになかなか取り込まれないってことで。

こんな記事もあった。（１月頃の記事）
外部ﾘﾝｸ:japan.linux.com
>Reiser4は、Linuxカーネル開発者たちによって拒否されたため、
>正式なカーネルおよびインストーラの一部としてはサポートしていません

569: 2005/06/08(水)02:07 ID:4YE2nrMe(1) AAS
reiserfs って 3 のときもひと悶着あったね。

570(5): 2005/06/08(水)04:26 ID:IZ76wtzA(1) AAS
mmには入ってるんだっけ？ > Reiser4

571: 2005/06/08(水)12:45 ID:jRFVsXNe(1) AAS
Reiserって今や出来の悪いレガシー扱いされてるからなぁ・・・

572: 2005/06/08(水)14:07 ID:74pqZXMt(1) AAS
>>570
はいっとる＞2.6.12-rc6-mm1

573: 2005/06/10(金)06:37 ID:yCzBxLKp(1/2) AAS
homeみてみたら、5M～15Mあたりのファイルが多かったんだがReiser使うにはでかすぎるかな
普通にext3使っとくか…

574: 2005/06/10(金)18:02 ID:P9msjoRr(1) AAS
そこでxfsですよ

575: 2005/06/10(金)23:50 ID:dHgAE2e0(1) AAS
Reiser4だね。

576(1): 2005/06/10(金)23:56 ID:yCzBxLKp(2/2) AAS
xfsって5～15Mあたりの大きさに適してるんですか?
大きいサイズって言うから少なくとも100M超かと勝手に思ってた。

数Bytes～4kBytes なら Reiserfs
5M～なら xfs って認識でOK?

577(1): 2005/06/11(土)00:16 ID:4GLdh6L7(1) AAS
xfsは細かいファイルだってかまわないで食っちまうファイルシステムなんだぜ

578(1): 2005/06/11(土)00:25 ID:5zO7UDA4(1) AAS
>>577
XFSってファイル消去がすげー遅かった記憶があるんだけど直ってる？
昔2.4カーネルにマージされる前に
# rm -rf /usr/src/linux
してえらく待たされた。

579: 2005/06/11(土)01:06 ID:p/bHJkl2(1) AAS
>>578
試してみたらHDD突然死した＿|￣|○

580: 2005/06/11(土)01:29 ID:U5YVO0VJ(1) AAS
過労でつか？

581: 2005/06/11(土)02:23 ID:hsNbI7ep(1/2) AAS
そもそも「そこで○○ですよ」とか言ってる香具師に反応した時点で釣られてることに気付け。

昔のXFSにくらべたら今のXFSは
「サイズは小さいが大量のファイルの生成/消去くりかえし」
の速度がかなり改善されてるが、
ReiserFSがダンチに速い状況はかわらず。
しかしXFSがメタクソに遅かったのって2.4.0-testXXXとかその頃じゃねーの?
今の2.4.31とか別に死ぬほど遅いとは思わんがな。

582: 2005/06/11(土)06:45 ID:k51zl/Fq(1) AAS
らいざーって読むんだね
レーザーって読んでた

583: 2005/06/11(土)09:42 ID:1+AbN8Zx(1/2) AAS
Linux界隈の人間は用途ごとに別のFile Systemを使おうとする件について

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の基本とかアルゴリズムなど不変な部分は教科書的に書いて、
実践編をこまめに改訂できれば良書になりそう。

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

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

ぬこの手ぬこTOP 0.032s