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

1 名前：login:Penguin [2006/11/25(土) 21:24:41 ID:BgxtdIS9] 過去スレ 01 pc.2ch.net/test/read.cgi/linux/1006743807/ 02 pc5.2ch.net/test/read.cgi/linux/1063025258/ 03 pc8.2ch.net/test/read.cgi/linux/1101495293/ 04 pc8.2ch.net/test/read.cgi/linux/1136695633/ 05 pc8.2ch.net/test/read.cgi/linux/1152348695/ 366 名前：300 mailto:sage [2006/12/25(月) 22:02:09 ID:u5v64fWw] 誤り訂正 アップルパーティションマップの仕様のリンク developer.apple.com/documentation/mac/Devices/Devices-121.html#MARKER-9-41 f-disk -l /dev/hda　→　mac-fdisk -l /dev/hda >>365 どうなるって、とり方次第でどうにでもとれて意味がよくわからん。 現状は/dev/hda3がext3でマウントされていて、読み書きできてる。 確認不足な点があるなら、追加するよ。 367 名前：300 mailto:sage [2006/12/25(月) 22:10:13 ID:u5v64fWw] もう一度誤り訂正 リンク先は>>359が正しかったorz マジ申し訳ない。 368 名前：login:Penguin mailto:sage [2006/12/25(月) 22:16:50 ID:xhvW4o8W] 謝りすぎすよｗ 369 名前：login:Penguin mailto:sage [2006/12/28(木) 20:16:52 ID:11msnvQ0] www.atmarkit.co.jp/flinux/rensai/watch2006/watch12a.html 370 名前：login:Penguin mailto:sage [2007/01/04(木) 23:31:25 ID:krLFR/+F] Linux: Chasing Down Data Corruption kerneltrap.org/node/7517 Linux: Data Corruption Bug Fixed kerneltrap.org/node/7518 371 名前：login:Penguin mailto:sage [2007/01/05(金) 23:50:17 ID:9EtcSPvI] gfs興味あるけど、資料少ないなー 372 名前：login:Penguin mailto:sage [2007/01/06(土) 09:56:21 ID:RHHwlQBc] GFS使ったことあるけど、Maildir形式のメールサーバ×４台に使ったら、 ファイルアクセスが遅すぎて使い物にならなかった。 大容量ファイル向きだわ。 GFS2でどこまで進化してるのに興味あるな。 373 名前：login:Penguin mailto:sage [2007/01/06(土) 12:01:58 ID:iH08ipQn] 使ったことあるならちょっと聞かせてくれ gfsって、LVMで分割したブロックを他のPCに持って行ってネットワーク経由でアクセスするって考え方でいいんだよな？ （もちろん、冗長化とかでA+AとかA+B+P+Qとかのモデルを取る場合もあるだろうが） で、LVMってのは、MMUのディスク領域版だよな？ ブロックに分割した領域が、セクタアドレスの再配置を伴って、見かけ一続きのブロック領域としてファイルシステムに提供されるという なんか根本的に間違ってるかな 374 名前：login:Penguin mailto:sage [2007/01/07(日) 12:14:00 ID:kV7nDToe] >>373 セットアップ人任せだったし、結構前だから、もうあまり覚えてないなー。 でもファイル読み書きはSANや共有SCSIで読み書きして、 ファイルロックを専用のネットワークでやるんじゃなかったっけ？ クラスタ組んでる内の１台がロック管理用のサーバになって、 他のホストがそのクライアントみたいな。 で、LinuxのLVMって、まだSistina GFS時代の頃にSistina社が オープンソースで提供したものだったから、 LVMもGFSも管理方法が似てるとかだったような…。 昔はググってもほとんど情報なかったけど、今はググれば情報あるんじゃない？ 375 名前：login:Penguin mailto:sage [2007/01/09(火) 01:43:47 ID:1r/HKlFu] 鯖運用するのにFSを何にするのかついつい迷ってしまう。 面倒だから ext3 でいいよね? 376 名前：login:Penguin mailto:sage [2007/01/09(火) 07:37:31 ID:pFKWUuBq] ファイルがぶち壊れるの、fsのせいかと思ったら、原因はmmap()だったのか… ttp://kerneltrap.org/?q=node/7518 377 名前：login:Penguin mailto:sage [2007/01/09(火) 08:09:00 ID:8ySvgupC] こんどはgetdentsが遅いって話になってるな。 378 名前：login:Penguin mailto:sage [2007/01/13(土) 00:17:35 ID:hhd3ra9J] ジャーナリングファイルシステムが保証するのはメタデータだけらしいですが、 逆にいうとタイムスタンプとかファイルサイズのメタデータが更新されてれば ファイルの中身は正しく更新されたと考えていいんでしょうか？ 379 名前：login:Penguin mailto:sage [2007/01/13(土) 00:18:27 ID:/hTyXuuv] んなわけない 380 名前：login:Penguin mailto:sage [2007/01/13(土) 08:50:01 ID:LPgOApau] メタデータの何を保証してると思ってるんだ? 381 名前：login:Penguin [2007/01/13(土) 13:50:32 ID:7SZBdiSI] 保証されるのはメタデータの一貫性じゃね？ データそのものはロストしてもファイルシステムの 健康は損なわれないってことでしょ。 382 名前：login:Penguin mailto:sage [2007/01/13(土) 14:40:37 ID:/ysw0X03] 希望と中途半端な理解がごたまぜになった妄想 383 名前：login:Penguin [2007/01/14(日) 11:07:16 ID:NA5ZaSYQ] chattr コマンドでは dump コマンドによるバックアップ対象に 含めるか否かなどのフラグを操作することができますが、 これらのアトリビュートは ext2/3 特有のフラグです。 xfs や jfs でも同様のアトリビュートの仕組みはあるのでしょうか？ 384 名前：login:Penguin [2007/01/17(水) 10:59:30 ID:XCRonxTk] >>217 古いネタになりますが.. ext3におけるジャーナル情報の記録はJournaling Block Device Layerを 通して行なわれるのであって、Generic Block I/O Layerが用いられるわ けではないため、リクエストのソーティングなどは行なわれないのでは ないでしょうか? 385 名前：login:Penguin mailto:sage [2007/01/17(水) 11:29:42 ID:83gvpb7N] >>382 つまりlost+foundにバックアップを取っておけば いざというとき幸せになれるということですね？ いい意味で 386 名前：login:Penguin mailto:sage [2007/01/17(水) 12:45:07 ID:wR6IvIw/] >>384 今は奥山はジャーナリングの不整合っていうのは取り下げていたような気が。 387 名前：login:Penguin mailto:sage [2007/01/17(水) 13:20:07 ID:NH1vWgwK] >>386 ソース希望 388 名前：login:Penguin mailto:sage [2007/01/17(水) 16:06:16 ID:wR6IvIw/] 「書き込み順序にエレベーターシークアルゴリズム などを用いるので、 Journal ファイルへの >　Journal 記録の反映順序保証さえない」というのは 最近言わなくなって、その前の「sync システムコールを呼び出しても、 保証されない」というのを声高に主張するようになっているんだったかな。 syncしても書き込まれなのは事実だし。 389 名前：login:Penguin mailto:sage [2007/01/17(水) 16:07:15 ID:wR6IvIw/] あ、syncしても書き込まれないから、ジャーナリング不整合になるという結論は変化なしか。 390 名前：login:Penguin [2007/01/17(水) 16:11:06 ID:dKhI4BNe] で、その結論は正しいの？ 391 名前：login:Penguin mailto:sage [2007/01/17(水) 16:19:09 ID:l/++G+GY] 奥なんとかさんに聞いとけ 392 名前：login:Penguin [2007/01/17(水) 16:36:28 ID:XCRonxTk] 最近のXFSはデータを準備してからメタデータを書くという噂を聞いたのだけど ホント? 393 名前：login:Penguin mailto:sage [2007/01/17(水) 18:07:01 ID:BxDmthED] ext3のデフォと同じじゃん 394 名前：login:Penguin mailto:sage [2007/01/17(水) 21:49:32 ID:5iSAbmWu] BSDのsoftupdateもヤバくなるから取り下げたんじゃないのん？ 395 名前：login:Penguin mailto:sage [2007/01/17(水) 22:28:40 ID:+AGvt5ET] >>394 ディスク側に持ってるキャッシュフラッシュのタイミングが気にいらん ってな、話だっけ? 396 名前：login:Penguin mailto:sage [2007/01/18(木) 01:21:11 ID:QSNRktCd] >>395 あと、FreeBSD 5.x以降ではLinux同様syncしてもflushされないのがわかったのもある 397 名前：login:Penguin mailto:sage [2007/01/18(木) 02:01:10 ID:jUaHNsmy] >>395 >　タイミングが気にいらん そういう話じゃないだろう ジャーナルに書き込んだがディスクはまだフラッシュしていない この状態でクラッシュすると、OSはジャーナルを書き込んだと思っているが実際には書き込まれていない 398 名前：397 mailto:sage [2007/01/18(木) 02:03:10 ID:jUaHNsmy] あ、すまん >395はソフトアップデートの話だったな スルーしてくれ 399 名前：login:Penguin mailto:sage [2007/01/18(木) 02:13:17 ID:4qrnvGep] キチガイって伝染するんだな 400 名前：login:Penguin mailto:sage [2007/01/18(木) 10:40:41 ID:vfB3lZBF] 400 うん 401 名前：login:Penguin mailto:sage [2007/01/18(木) 21:07:25 ID:jUaHNsmy] ついでだが、>397の状態でも常に問題が起こらないとする そうすると、ジャーナルは無用の長物だということにならないか？ 402 名前：login:Penguin mailto:sage [2007/01/18(木) 22:08:12 ID:fQv5Q68V] 問題では歩けど解決策が...ってことだろ 403 名前：login:Penguin mailto:sage [2007/01/19(金) 02:41:03 ID:6XfomkSC] ヒント：再起動 404 名前：login:Penguin mailto:sage [2007/01/19(金) 12:31:32 ID:T0ADJeSd] まさに伝家の宝刀 405 名前：login:Penguin mailto:sage [2007/01/19(金) 20:39:33 ID:4t6qqCPq] ジャーナル破損→再起動→ファイルシステム破損 >>403-404 本当にどうも有難うございました 406 名前：login:Penguin mailto:sage [2007/01/20(土) 11:26:20 ID:UaLVa0QY] 壊れるのは書き込みの順序が原因で、syncしないことは別問題 407 名前：login:Penguin mailto:sage [2007/01/20(土) 11:35:29 ID:gfquQKqH] 先生、質問！ １．書き込みの順序の問題が起こっているのはなぜですか？ ２．syncしないことで起こる別問題って何ですか？ 408 名前：login:Penguin mailto:sage [2007/01/20(土) 12:10:54 ID:KTOxmzQl] ２は、データ自体が不正になってしまうことだな。 チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。 チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。 これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。 １は、媒体エラーによってもたらされるものだろう。 ジャーナルの再作成、fsckが必要になる。 lost+foundに前回のチェックポイント以降の更新データが保存される。 409 名前：login:Penguin mailto:sage [2007/01/20(土) 12:17:24 ID:gfquQKqH] 返事がないようなので、もうひとつ ３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？ 410 名前：login:Penguin mailto:sage [2007/01/20(土) 13:45:07 ID:gfquQKqH] 返事ぐらいしろよ つまらないのでWindows2000の話 [書き込みキャッシュを有効にする] 機能を有効にすると、データが失われる support.microsoft.com/kb/281672/ 書き込みキャッシュが有効な場合の遅いディスク パフォーマンス support.microsoft.com/kb/332023/ja 「この修正プログラムは、実装に伴うリスクのレベルを理解および承諾し、 適切なハードウェアの電源保護によってこのリスクを軽減できるという確信がない限り、 実装しないでください。」 411 名前：login:Penguin mailto:sage [2007/01/20(土) 14:47:24 ID:UaLVa0QY] 書き込み順序の問題はディスクのcacheが原因 slashdot.jp/linux/article.pl?sid=02/09/18/0623254&mode=nested 412 名前：login:Penguin mailto:sage [2007/01/20(土) 15:01:37 ID:UaLVa0QY] >>２．syncしないことで起こる別問題って何ですか？ ディスクに確実に書き込まれたことを保証しないといけない場合に困る。 syncの呼び出し後にネットワークで書き込み終了を通知したが、 実際に書き込まれる前に電源が落ちるといったケースが考えられる >>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？ syncによって順序を保証する手法もある。 詳細はlinux/Documentation/block/barrier.txtを参照。 但し、処理によっては実用にならない程遅い可能性もある。 413 名前：409 [2007/01/20(土) 15:15:27 ID:gfquQKqH BE:454855493-2BP(0)] >>412 >　>>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？ >　syncによって順序を保証する手法もある。 実はここが聞きたかったわけで、そうすると >>406 >　壊れるのは書き込みの順序が原因で、syncしないことは別問題 別問題とは言えないことを自ら返事されたわけです 414 名前：login:Penguin mailto:sage [2007/01/20(土) 15:54:53 ID:UaLVa0QY] >>413 確かにそうだけど… softupdateなんかで依存の発生する場所全部にsyncを入れるのが 現実的？非現実的である証拠のデータが出せなくて申し訳ない ですが… 415 名前：login:Penguin [2007/01/20(土) 16:16:11 ID:gfquQKqH BE:1078176588-2BP(0)] いえ、データ出すのは大変ですから Windows2000でさえ両方の含みを残している 難しい判断なんでしょうね 416 名前：login:Penguin mailto:sage [2007/01/20(土) 17:08:10 ID:UaLVa0QY] ついでに、これも転載 lists.freebsd.org/pipermail/freebsd-stable/2006-September/028251.html 417 名前：login:Penguin mailto:sage [2007/01/20(土) 17:25:35 ID:snxMEiUl] >>416 そのスレを読んでいくと、ジャーナリングでもsoftupdate同様に todays desktop drives can lie about writing data. の影響を受けるっていう、このスレの流れと同様の話になっていっていますな。 418 名前：login:Penguin mailto:sage [2007/01/20(土) 23:02:52 ID:SqdA4hO3] ハードディスクが独自に高性能化を辿った結果、 書き込み順についてはどんなに直接sync命令しても確実に保証されるものではないってことかな? 今のhddじゃエレベーターシークアルゴリズムとかは意味がないか逆効果かもとどっかで見たことあるし。 419 名前：login:Penguin mailto:sage [2007/01/21(日) 02:52:54 ID:hY5qL1VD] >>418 SCSIとSerial ATA 2.5はFUAによってwrite cache有効時でも書きこみの完了を保証できる。 ので、ドライバがまともに実装されていればOK。 ATAはcache flushを保証する手段が用意されていないので何をやっても無理。 420 名前：login:Penguin mailto:sage [2007/01/21(日) 20:35:19 ID:4gtXWK3A] ZFSではwc対策はどうなっているの？ 421 名前：login:Penguin mailto:sage [2007/01/21(日) 23:48:40 ID:AqF7ihH/] しかし、ジャーナリングファイルシステムって、電源断とかのトラブルでも ファイルが壊れないようにするものじゃないのか。 実験室での使用なので、けっこう動作環境が良くないのは分かるけど 今日、ext3 また壊れてしまった。フォーマットからやりなおし。 土曜にバックアップとっていて良かった。 やっぱりXFSに移行するかな。 422 名前：login:Penguin mailto:sage [2007/01/21(日) 23:55:06 ID:xsvOt/km] ext3が何度も壊れ、 reiserfsの大パーティションのマウントの遅さが嫌になり、 XFSに行き着いて幸せになった俺 423 名前：login:Penguin mailto:sage [2007/01/22(月) 00:14:17 ID:ppnVbPRo] たしかに reiserfs はでかいパーティションのマウントに時間がかかるね 424 名前：login:Penguin mailto:sage [2007/01/22(月) 00:19:23 ID:RyHURUu7] ちょっと気になったのは、このスレの過去ログ読むとLinuxのVFSのせいで XFSでもファイルシステムが壊れるって聞いたけど、どうなの? 425 名前：login:Penguin mailto:sage [2007/01/22(月) 00:34:54 ID:Mwx+Gzyg] XFSはファイルシステムが壊れるよ ext3はファイルは守ってくれないが ファイルシステムは守ってくれるので まだ安心 426 名前：login:Penguin mailto:sage [2007/01/22(月) 00:56:30 ID:RyHURUu7] それじゃ、ダメじゃん。 427 名前： ◆IIiDC8JS7w mailto:sage [2007/01/22(月) 00:59:28 ID:v/DQ0Ap0] ZFS to the FUSE まだα版だけど。。 つ ttp://developer.berlios.de/projects/zfs-fuse/ 428 名前：login:Penguin mailto:sage [2007/01/22(月) 02:58:08 ID:4mh5V91p] まぁいろいろ悩む前にUPS買えってことで。 あとは日々のバックアップ。 429 名前：login:Penguin mailto:sage [2007/01/22(月) 04:59:17 ID:g7VFvdpY] FUSEじゃ読み書きできますよっていう程度で、本格的に使うのには 全然向かないな… 430 名前：login:Penguin mailto:sage [2007/01/22(月) 19:52:31 ID:aXULs4Jv] GFS使ってる人、手ageて。 431 名前：login:Penguin mailto:sage [2007/01/22(月) 19:54:33 ID:I6ul0rfb] デスクトップでJFS使い始めました。 前はReiserFSでした。 今のところ無問題。 432 名前：login:Penguin mailto:sage [2007/01/22(月) 21:44:43 ID:CllrhvyS] >>421 どんなFSでも、ジャーナルにしてもRAIDにしてもファイルが壊れない (壊れ難い)という認識は止めたほうが安全。 復旧を早くする方法論と割切ったほうがいい。 大切なデータはきちんとバックアップすること。 433 名前：login:Penguin mailto:sage [2007/01/22(月) 21:46:12 ID:vkPy7i3I] >>431 毎日cvsでgcc取ってきてビルドしてみて。 漏れは3年前emacsでそれやってたらfs壊した(XFS)。 434 名前：login:Penguin mailto:sage [2007/01/22(月) 22:03:40 ID:+MxoKgNb] XFS ってそんなに弱い子なのか。 435 名前：login:Penguin mailto:sage [2007/01/22(月) 22:11:02 ID:gyatXghJ] gentooでほぼ毎日何かしらをコンパイルしたり、 時々動画をエンコしたり、 毎日えろまんがを読み漁っていますが、 XFSは元気です。 436 名前：login:Penguin mailto:sage [2007/01/22(月) 22:18:21 ID:6fw9D8r3] ファイルシステムを何にしてもHDDガリガリさせるのは 寿命を縮めるだけだから、できることならあまりやりたくないね。 437 名前：login:Penguin mailto:sage [2007/01/23(火) 00:06:35 ID:yhm1O3f9] >>436 それじゃlocateが動くLinuxは使えんがな。 438 名前：login:Penguin mailto:sage [2007/01/23(火) 10:58:00 ID:SMWMFAIy] locate は使えば便利なんだけど 知らない人とか使わない人にとっては負荷が無駄過ぎるな。 デフォルトで動くディストリも結構あるんじゃないの。 439 名前：login:Penguin mailto:sage [2007/01/23(火) 13:21:33 ID:Dh6zD8CC] HDDの代わりにi-RAMとかフラッシュディスクを使えば解決 440 名前：login:Penguin mailto:sage [2007/01/23(火) 13:28:42 ID:dy5DSgJl] ガリガリ使えばHDDよりフラッシュのほうが寿命短いんじゃないの？ 441 名前：login:Penguin [2007/01/23(火) 14:18:58 ID:Qe3f9h84] そこでMRAMとか相変化RAMとかですよ！ 442 名前：login:Penguin mailto:sage [2007/01/23(火) 14:32:40 ID:L6fiHwdO] HDD の寿命とか気にしてたらまともに使えんだろう 443 名前：login:Penguin mailto:sage [2007/01/23(火) 15:01:52 ID:5Whe9XEV] フラッシュの方が圧倒的に短いわなｗ 444 名前：login:Penguin mailto:sage [2007/01/23(火) 16:30:58 ID:JInqPF8n] ハイブリッドハードディスク楽しみだよねえ。っと。 www.itmedia.co.jp/news/articles/0504/26/news018.html # スレ違い。 445 名前：俺用メモ mailto:sage [2007/01/23(火) 16:48:37 ID:JpiPeEcZ] <kernel-src>/Documentation/filesystems/ext4.txt 　　NOTE: The "extents" mount flag is temporary. It will soon go away and 　　extents will be enabled by the "-o extents" flag to mke2fs or tune2fs www.die.net/doc/linux/man/man8/mkswap.8.html 　　For kernels after 2.3.3 there is no such limitation www.die.net/doc/linux/man/man8/mkfs.xfs.8.html 　　the maximum size is just under 1 TiB. 446 名前：login:Penguin [2007/01/23(火) 17:00:50 ID:xbr0LMQ0] FUA 関係なくデータのロストが防げるなら フラッシュは大歓迎なんだけど、 そういう目的じゃないようなので Intel の Robson でいい気もする。 447 名前：login:Penguin mailto:sage [2007/01/23(火) 17:14:46 ID:0oMO9Ojw] >>446 >　FUA 関係なくデータのロストが防げるなら ハイブリッドディスクはデータロストしないんじゃねぇ？ ライトキャッシュが不揮発性というのは大きいと思うんだが 448 名前：login:Penguin mailto:sage [2007/01/23(火) 17:34:03 ID:0oMO9Ojw] もちろん、ソフト側が正しく制御する前提だけど 449 名前：login:Penguin mailto:sage [2007/01/23(火) 21:19:21 ID:SMWMFAIy] フラッシュメモリってライトキャッシュに使えるほど 書き込み耐久性あるの？ 450 名前：login:Penguin [2007/01/23(火) 21:27:38 ID:xbr0LMQ0] フラッシュに入る前にも当然8MB程度の RAMがキャッシュメモリとして確保されていると思われ。 なのでその部分はやはり揮発すると思う。 451 名前：login:Penguin mailto:sage [2007/01/23(火) 21:44:21 ID:L4TUXWzd] >>450 揮発するといってもトランザクションを実行するくらいの コンデンサ容量は確保されてるでしょ・・・・ 452 名前：login:Penguin mailto:sage [2007/01/23(火) 21:51:03 ID:0oMO9Ojw] >>450 ハイブリッドハードディスク www.google.co.jp/search?hl=ja&q=%E3%83%8F%E3%82%A4%E3%83%96%E3%83%AA%E3%83%83%E3%83%89%E3%83%8F%E3%83%BC%E3%83%89%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr= どこにも8MB程度のRAMのキャッシュメモリの話はないですが 自分で確認してください 453 名前：login:Penguin [2007/01/23(火) 22:17:31 ID:xbr0LMQ0] >>452 DRAM のキャッシュと不揮発のキャッシュを 併用することになっている。 pc.watch.impress.co.jp/docs/2006/0526/hot428_01.jpg 454 名前：login:Penguin mailto:sage [2007/01/23(火) 22:23:32 ID:0oMO9Ojw] >>453 japanese.engadget.com/2006/05/08/hybrid-hdd/ ハードディスクドライブのバッファを大容量NANDフラッシュメモリに置きかえたハイブリッドHDD 455 名前：login:Penguin mailto:sage [2007/01/23(火) 22:35:32 ID:8K+SLyEi] 開発者の発表スライドにengadgetの記事で反論する珍行動 456 名前：login:Penguin [2007/01/23(火) 22:52:33 ID:xbr0LMQ0] >>454 そうは言うが、Samsungのホワイトペーパーでも First, Hybrid HDD has flash memory playing a supplementary role to DRAM in order to dramatically reduce the boot time and improve system capacity. www.samsung.com/Products/HardDiskDrive/whitepapers/WhitePaper_12.htm とあるので、DRAMによるキャッシュも積んでいるんだと思う。 DRAM→NVRAMはいきなりの電源断でも書ききれるという意味で データが失われないという仕組みは可能だと思うが、 DRAM無しというのは難しいんじゃないか？ そもそも上に出したWinHEC2006のスライドも元は Samsungの描いた絵だし。 457 名前：login:Penguin mailto:sage [2007/01/23(火) 23:51:46 ID:0oMO9Ojw] >>456 >>453の図と>>456の図はほぼ同じなんだが、どちらの図にもI/O両方の矢印がある この両方向でDRAMをスルーしてNVRAMにアクセスしている ハイブリッドディスクはブート時に1-2KBのRAMにブートセクタをコピーするんだが、このDRAMキャッシュはその部分の事ではないのか？ >>456を翻訳しても、ズバリ、キャッシュに使っているというようには訳せないんだが 458 名前：457 mailto:sage [2007/01/24(水) 00:17:56 ID:vzigmnXE] ×　NVRAM ○　NANDフラッシュメモリ 459 名前：login:Penguin mailto:sage [2007/01/24(水) 00:38:31 ID:uMM8sw+h] だから MRAM,FeRAM とかの高速不揮発メモリに 期待って話だったんじゃねーの? 460 名前：login:Penguin mailto:sage [2007/01/24(水) 01:39:30 ID:Wx+4qs1R] 耐久年数と揮発/不揮発は関係あるの？ 461 名前：login:Penguin mailto:sage [2007/01/24(水) 02:19:19 ID:OH8//z4U] 耐久年数が多いと揮発しにくいので、一度書いたら 上書きがとても大変 462 名前：login:Penguin mailto:sage [2007/01/24(水) 08:32:43 ID:vzigmnXE] >>460 現行のフラッシュメモリは耐久年数は低いとされている しかし、>459のMRAMは耐久年数のみならずスピード自体も揮発性メモリより高い FeRAMもMRAMに準ずる 463 名前：login:Penguin mailto:sage [2007/01/24(水) 15:27:52 ID:fll6hQgJ] フラッシュメモリが高い耐久性を持ってなきゃいけない必要性はない。 ハミング符号なりで保護して不良部分を置き換える下のレイヤーを一 層設ければ耐久年数は無視できる問題ではないか? 464 名前：login:Penguin mailto:sage [2007/01/24(水) 16:04:57 ID:vzigmnXE] webleverage.jp/xen/wiki/index.php?howto#m6961cbc Intel Macのマルチブートっておもしろいねえ OSX用と全く同じ内容のMS-DOS用のパーティションテーブルを作ってるよ 465 名前：login:Penguin mailto:sage [2007/01/24(水) 16:17:28 ID:mEXlFMcS] >>463 そういうのも含めての耐久性じゃない？ 466 名前：login:Penguin mailto:sage [2007/01/24(水) 16:22:03 ID:vzigmnXE] >>463 現状すでにやられてる話でしょ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef