[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 07/26 10:56 / Filesize : 187 KB / Number-of Response : 762
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

/**ファイルシステム総合スレ その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/

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]
謝りすぎすよw

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形式のメールサーバ×4台に使ったら、
ファイルアクセスが遅すぎて使い物にならなかった。
大容量ファイル向きだわ。

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で読み書きして、
ファイルロックを専用のネットワークでやるんじゃなかったっけ?
クラスタ組んでる内の1台がロック管理用のサーバになって、
他のホストがそのクライアントみたいな。

で、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]
先生、質問!
1.書き込みの順序の問題が起こっているのはなぜですか?
2.syncしないことで起こる別問題って何ですか?

408 名前:login:Penguin mailto:sage [2007/01/20(土) 12:10:54 ID:KTOxmzQl]
2は、データ自体が不正になってしまうことだな。
チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。
チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。

これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。

1は、媒体エラーによってもたらされるものだろう。
ジャーナルの再作成、fsckが必要になる。
lost+foundに前回のチェックポイント以降の更新データが保存される。


409 名前:login:Penguin mailto:sage [2007/01/20(土) 12:17:24 ID:gfquQKqH]
返事がないようなので、もうひとつ
3.自由なタイミングで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]
>>2.syncしないことで起こる別問題って何ですか?
ディスクに確実に書き込まれたことを保証しないといけない場合に困る。
syncの呼び出し後にネットワークで書き込み終了を通知したが、
実際に書き込まれる前に電源が落ちるといったケースが考えられる

>>3.自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか?
syncによって順序を保証する手法もある。
詳細はlinux/Documentation/block/barrier.txtを参照。
但し、処理によっては実用にならない程遅い可能性もある。

413 名前:409 [2007/01/20(土) 15:15:27 ID:gfquQKqH BE:454855493-2BP(0)]
>>412
> >>3.自由なタイミングで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]
フラッシュの方が圧倒的に短いわなw


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
現状すでにやられてる話でしょ

467 名前:login:Penguin mailto:sage [2007/01/26(金) 03:11:35 ID:9ovjxSc8]
現状でも、書き込み寿命の均一化はやってあるよ。
それでやっと今の寿命になってる。

個人的には、停電時にファイルを確実に守る方法は
UPS以外に有効な方法は無いと結論をだしてる。







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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<187KB

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