【瓦記録】SMRのHDD 4台目【ﾌﾟﾗｯﾀ枚数減】
■ このスレッドは過去ログ倉庫に格納されています
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
プラッタ枚数を減らし、価格が安くなるかわりにがランダム書き込みが致命的に遅くなる技術
Shingled Magnetic Recording (SMR)を採用した、通称瓦記録のHDDについて語りましょう
Shingled Magnetic Recording: Boosting Capacity and Lowering Costs
https://sata-io.org/developers/sata-ecosystem/shingled-magnetic-recording-boosting-capacity-and-lowering-costs
HDDの大容量化をけん引する瓦記録技術 - 東芝
https://www.toshiba.co.jp/tech/review/2015/08/70_08pdf/a08.pdf
SMR におけるビット信頼度への隣接ビットの影響 - 日本磁気学会
https://www.magnetics.jp/kouenkai/2015/doc/program/44ALL.pdf
スマートストレージ・スタックベースHBAおよびRAIDソリューションでのSMRドライブの使用
https://storage.microsemi.com/nr/pdfs/microsemi_adaptec_smr_whitepaper_ja.pdf
前スレ
【瓦記録】SMRのHDD 3台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1541073336/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>377
それはわからん。SMRがそれを意識して動いてるならあるだろうし
意識してないならないんじゃね
そもそもCMRではトラックのサイズなんてあんまり意識して動いて無いから
トラックサイズは一般的では無いんでしょ
何故意識する必要が無いのかは隣接するトラックへのシーク時間が極小だからなわけで
だとするならSMRにおいてもトラック毎に区切って考える必要はあまりなく
他の事象を優先に考えて動いている可能性も大いにある
例えば書き込み先のトラックサイズに依存して更新サイズを可変させるのは
制御が困難になるから更新サイズは固定長にしようとかな バンドのサイズを超えるか超えないかで処理に違いが発生するという話であって
トラックのサイズはバンドのサイズを決める上での要素の一つ。バンドサイズが固定長ならトラックのサイズは無視されてるだろうし。 >>380
いやまて、バンドサイズはトラックサイズ×バンド数の事だと思ってたんだが違うのか？ バンドサイズを固定長にする為にあえてあまらせるという選択肢も無しじゃないなと。
バンド更新の際に同じ場所に書き換えるのならバンドサイズ可変でも良いけれど、
追記をしているのならバンド可変は手間が増えるんじゃないかと。
他にもガベージコレクションとか考えるとサイズ固定もメリットあるなと。
2016年の記事にガベージコレクションやらバンドは書き換えじゃなくて追記とか言う内容のモノもあるんだよね。
年代的にAS002のことを言ってるんだと思うけれど。 >>382
バンドサイズを最短のトラックサイズに合わせるって事？
流石にそれはないだろ。トラックって最長と最短で倍位は差があるんだろ 別に合わせんでもいいのでは
サイズ差はキャッシュがでかい方に合わせりゃいいじゃん >>383
仮にバンドサイズ20MBだとすれば
トラック1本10MBのエリアならトラック2本でバンドを構成、
トラック1本8MBのエリアならトラック3本でバンドを構成。3本で24MB分確保して4MB余った状態になる。
トラック1本5MBのエリアならトラック4本でバンドを構成。
という手段も取れるというだけの話だろう。
ガベージコレクション的な再配置を行うのならサイズ固定の方が手順が軽いだろうし。 とりあえず >>386 の日本語の奴にバンドを書き換える場合は
一度メディアキャッシュに書き出すって書いてあるな
コスト倍どころじゃ済まないはずだけどよく誤魔化せてるもんだな
あとシーケンシャルライトはサイズによってはメディアキャッシュ使わないのも書いてあった
どうやってるのかは書いて無かったけどまっさらなバンドだけをかき集めて書いていくのかな
見つからなかったらどうするんだろうな OS的にはメディアキャッシュが更新できた時点で処理完了 パーティション切る時にバンドをまたいでる場合って何か悪影響ある？ >>390
基本的にはそうなんだろうけど裏でメディアキャッシュからバンドに
書き出してる最中にメディアキャッシュにアクセスしたら
ランダムアクセスっぽくなったりしないんかなとか メディキャッシュからの書き戻し作業中にホストからデータがきたらホストのデータ優先。
書き戻し作業などはいつでも放棄できるような手順になってるはず。
ホストのデータを優先できなくなると極端な速度低下症状に繋がる >>394
ってバンド書き込みの中断処理入るならそれはそれで
ホストからのリードも遅くなる気がするが体感できる程は遅くならないのかね そもそもがドライブ独自に動いてる処理なんだから、常に中断に備えたフローになってる。
だから書き戻し作業も放棄すればいいだけ。
再開は作業完了の記録が無ければその作業を初めからやり直すだけ。 ん？
バンド単位の書き戻しが始まっていたら、その1バンド分は中断出来んだろ？
1バンド分を不揮発性の領域に一度書き込んでからなら出来なくはないが、
そうでないなら、瓦書きの途中でやめたら、もうそのバンドのデータは次回の読み込みでは信用できなくなる。 >>397
「元データは必ずキャッシュかCMR領域のどちらかにある」ってやつじゃね？
書きかけだったSMR領域は破棄で次の書き戻し機会に全部上書きとか http://www.idema.gr.jp/common/pdf/news/tenbo2019.pdf
去年は配布がなかったIDEMA JapanのストレージとHDDの業界展望2019のpdf出てたから貼っとく
SMRについてどうこうってことは無いけどまとめ的な感じでいいかなと >>398
中断前提ならそうするしかないよね？
遅くなるけど。 >>400
>>386 にもバンド更新時は対象のバンドは一度メディアキャッシュに書かれると書いてある >>401
たしかに！
386の言うとおり、コスト倍以上だよね。
データベースのファイルとか絶対に置きたくないな。 2.5インチが750GBになってるな。
IDEMAとしては1TBプラッタの存在は認識してないってことか。
それなりに信頼のおける団体の資料だし、1TBプラッタはSMRしか無いとみていいのかね。
ベンチなんかで既にいろいろとネタは上がってきてるから今更なんだけど、
ユーザーじゃない立場の発行した資料でこういうのを見るとトドメな感じがしてしまう。 >>402
そもそもメディアキャッシュの書き戻しはバックグラウンドで行われるものだから
キャッシュが溢れない限りは全く関係ない話だよ。
むしろランダムライト自体はCMRのみよりも高速になる。 >>403
750GBプラッタだと東芝のMQ03ABD300（750GB x4）がだいぶ前から出ている
それとは別にWDのWD40NPZZがCMRだと言われていて、もしそうなら800GB x5と言う事になりそうだ >>405
いや、昭和電工発表の1TBプラッタがSMRで確定かねというはなし >>404
バックグラウンドだからまったく関係無いっつーのは安直じゃね？
というか普通バックグラウンドだから大丈夫っていうのは
バックで別の人が別のリソース使用して作業してるから言えるのであって
この場合バックもフロントも同じディスクやヘッドだからな バックからフロントへのリソース切り替えで躓いたらそのまま
フロントの処理遅延に直結するじゃんかと 正に店員が一人のコンビニと同じ状態だな
品出しはバックグラウンドだからノンビリやっても客には影響無いかってそんなわけはなく
バックグラウンドからレジに出るのに遅れたらその分客は普通に待たされるっていう メディアキャッシュの操作はドライブファームの管理下にあるんだし、
ホストからアクセスがある間は書き戻しを行わなければ済む話では？
ドライブファームによる独自の動作をしてる状態に
ホストの指示が有った場合の復帰のペナルティに関しては
内部を解析でもせん限りはりわからんでしょう。
ホストからの指示に従う部分とSMR動作を行う部分のリソース共有度合次第だろうし。
でも仮にペナルティが有るんだとしても、
シーク動作とかのタイムスケールに比べたら微々たる問題じゃないかね。 ホストからのアクセスが続くとメディアキャッシュがあふれて動作遅延が出るってのは
シーゲイトのSMRの症状そのものでしょ。
これはつまりホストからの動作が優先されてることの証明だと思うけれど。
ホストからの指示を押しのけてまでキャッシュ書き戻しを行うのであれば
この症状は出てないと思うし。 >>407
何視点で語ってんのか統一しないと意味ない
OSかファームか ヘッドが三個ぐらいあって、役割を分担出来れば良くなりそう。 受け取りデータのSMRバンドへのフラッシュはWDなダイナミックマッピング方式と
海門なスタティック方式とではちょっとやり方が違うみたいね。ただし両社に共通している点はある。
瞬間停電なような電源断が発生しても上書き前のデータをきちんと保持できるような
安全面が考慮して常時HDD上のどこかに書き換え前のバンドを保存してあること。
WD的には上書きせずに追記。海門的にはスクラッチ保存後に上書きという二度書き。
ま、現用機の実装が上記の通りであるかはしるよしもないけれどw
----------
The cost of cleaning a band may vary based on the type of the block mapping used. lWith dynamic mapping an STL can read a band, update it in memory, write the updated
band to a different band, and fix the mapping, resulting in a read and a write of a band.
With static mapping, however, an STL needs to persist the updated band to a scratch
space first―directly overwriting the band can corrupt it in case of a power failure―
resulting in a read and two writes of a band. 安全面が考慮して >> 安全面を考慮し
以下オマケ
-------
shows the logical view of Seagate ST8000AS0002 DM-SMR disk that was recently
studied in detail. With an average band size of 30 MiB, the disk has over 260,000 bands
with sectors statically mapped to the bands,
and a -25 GiB persistent cache that is not visible to the host. The STL in this disk
detects sequential writes and starts streaming them directly to the bands,
bypassing the persistent cache. Random writes, however, end up in the persistent cache,
dirtying bands. Cleaning a single band typically takes 1-2 seconds, but can take up to 45
seconds in extreme cases. >>414
ダイナミックマッピング方式は上書きせずに追記。ということで >>229 のサルベージ屋さんの
ガベコレ話を思い出すのだが、ガベコレが実バンドアドレスと論理バンドアドレスの不整合の
解消を目的として本来あるべきバンドに追記分を書き戻す。ということならアリかもしれない。
これに対してスタティックマッピングではバンドは常に実バンドアドレスであるからそんな
囲い戻しは不要。かもね。
ダイナミックマッピング方式だと書き換えが生じると別バンドへ追記書きが生じるから
ファイルの連続性は機械的に失われる。そもそもDBのようなランダムファイルでしか
そんな追記は起こらないから、まあいいか。というニュアンスなのかもね。
このダイナミックマッピングだとマップテーブルが壊れた場合のサルベージはスタティック
方式より難しくなりそうね。俺的にはHDDが壊れた場合のサルベージ難度を考慮すると、
サルベージ用のソフトもイロイロ手元にあるので。こっちかな。みたいな。 >>413
それだ！
ディスクは回っているだけだから、
メディアキャッシュから本来の位置へ書き戻す専用ヘッドがあれば、かなり耐えられる。
振動ヤバそうだけど(笑) そこまでコスト掛けるならメディアキャッシュやめてNANDでかいの積んだほうがよさそうだけどね。
MACH.2の2分割駆動をうまく生かす方向なら何とかなるかもしれんけど、
2分割なら動作を連携させるよりも完全分離の方がよさそうだし。
SATAコマンドを2系統同時に処理するみたいな話のようだし Seagateの同時投入された14TB HDDに使われてる新型1.75TBプラッターはCMRと言われてたのに、
https://www.facebook.com/seagatemy/photos/announcing-the-14-tb-exos-x14-cmr-enterprise-hard-drive-offering-maximum-density/2273902799349121/
> Announcing the 14 TB Exos X14 CMR Enterprise hard drive, offering maximum density, scalability, power efficiency and security.
https://www.kitguru.net/components/hard-drives/simon-crisp/seagate-exos-x14-14tb-hdd-review/
> Recording Method: conventional magnetic recording (CMR)
同じスペックのプラッターのX14 14TB ST14000NM0428がHost Managed SMRと書かれてる
1.75TBプラッターが全てSMRなのか誤記なのかHM SMR互換のCMRなのか、よく分からない
Seagate Exos X14 14TB 512E SATA HM SMR Product Manual
EXOS X14 14TB ST14000NM0428 / ST14000NM0448
ZAC Host Managed zoned device.
https://www.seagate.com/jp/ja/support/internal-hard-drives/enterprise-hard-drives/exos-X/
https://www.seagate.com/files/www-content/product-content/enterprise-hdd-fam/exos-x-14/en-us/docs/100829477b.pdf
1.75TBプラッター 14TB
BarraCuda Pro 14TB ST14000DM001
IronWolf 14TB ST14000VN0008
IronWolf Pro 14TB ST14000NE0008
SkyHawk 14TB ST14000VX0008
EXOS X14 14TB ST14000NM0018 / ST14000NM0258
EXOS X14 14TB ST14000NM0428 / ST14000NM0448
Heads 16
Discs 8
Recording density, KBPI (Kb/in max) 2426
Track density, KTPI (ktracks/in avg.) 436 (トラック密度がSMR 2TBプラッターより明らかに低い)
Areal density, (Gb/in2 avg) 1058
SMR 2TBプラッター
BarraCuda 4TB ST4000DM004
Recording density (max) 2294 kB/in
Track density (avg) 540 ktracks/in
Areal density (avg) 1203 Gb/in^2 ひょっとして6年前の2TBより今の2TBって性能が下がるのか？ 文書のタイトルでHMSMR明記してるんだしSMRじゃないってことは無いと考えると
データシートをコピペして修正忘れというオチじゃないかな？
仮に同じ磁気記録密度のプラッタをベースにしてSMRを採用したとしても、
SMRバンド間のガードバンドの存在やセクターギャップのことを考えると
CMRでの記録スペックと同じになるわけないと思うし。
それをわざわざ同じにするメリットもない。 新しい技術の一般化、はよ
SMSR課なんかそんな感じの奴 >>414
そらそうだろ。そんな理由での破損させたら大問題というか笑い者にされる。キャッシュクリア時の処理なんて昔から色々試行錯誤されていて枯れた技術も沢山あるし
問題は書き込み直後のハッシュチェックが何の意味も無い事かな。まぁ元々念の為のモノだけど同レベルを求めるとメディアキャッシュクリアしてからになるし、そもそも同一バンド(？)の書き替えで書き替え発生するからSMRで気にしたら負けかなww 3.5インチは東芝だけCMRで、他社はみんなSMRに移行した、でOKなのかな？
複数チューナーによる同時録画などはまだCMRじゃないと駄目だけど、
一般人の通常用途ならパワーアップしたSMRでアーカイブ以外の使用も可能になった。
これであってる？ WDもシーゲイトもDMSMRは最安ラインのみ
東芝もSMRを出す準備は進めてる
「一般人の通常用途」の定義が不明
使用に問題が出るかどうかの判定境目はドライブファームにランダムライト判定される書き込みが
メディアキャッシュ容量以上に連続するかどうか。
WDとシーゲイトではDMSMRの制御方式が違うので同一視はしないほうが良い 2.5インチのSMR化が進んでるのは確かだけど
3.5インチはまだまだじゃない？ 大容量化のために5インチHDDの復活を容認する消費者は過半数だと思うけど、
それをしないのは技術的に難しいのかな >>435
いっそのこと 8インチドライブはいかが？ って大昔ぷらっとほーむ開業直後本多のオヤジに
日立の8インチを押し売りされたことあったなあ。SMDインタフェースのやつ。
8インチHDDが先端技術だった頃はウィンチェスター型ハードディスクとか呼ばれていた。
海門の前身はIBMの外部記憶開発エンジニアだったアラン・シュガートがスピンオフして
立ち上げたシュガート ・アソシエイツ。8インチのみならず5インチFDDのデファクト。
そのシュガート が次に立ち上げたシーゲートの大ヒットがST-506。5MBの5インチフルハイトHDD
PC/XTの標準内蔵HDD。これも初期PCのデファクト。
外観的にあの時代に戻るノスタルジーを感じるのはやっぱり爺だけだろうね。終活乙。 >>426
CMRなHDDって伝統的にターゲットセクタに直な上書きしかしないでしょ。
スクラッチセクタに別書き一時保存とかはしない。だから瞬間停電とかの事故対策が重要で
Unix系ではトランザクションとかジャーナリングとかHDDの外側で対策が図られてきた。歴史。
瞬停電対策という点でSMRはスクラッチ保存という護送船団的な保護機能の点でCMRより
安全性が高いと言えるかもしれないね。SMR逝くときは去くだろうけど。気持ち少しだけ。 5インチや8 インチって今どきの記録密度で外周まともに読めるのか？
おまけにモーターが大変なことになりそう >>437
ようわからんがそのCMRのターゲットセクタの書き込みってのが
SMRのメディアキャッシュの書き込みにあたるだけじゃないのか？ シーゲイトがSMRのメリットとしてメディアキャッシュに一旦書ききることの安全性をPRしてるんだし
それなりの意味はあるんじゃない？
ターゲットセクタへのちまちまとしたランダムライトよりも
メディアキャッシュに一気に書ききるほうが
データもらってから不揮発媒体への記録完了が速いのは確かなんだし。
ただしそれはSMRのメリットじゃなくてメディアキャッシュのメリットだけど。 なるほど、物は言いようか
いや、ランダムライトな物はメディアキャッシュ内でもランダムライトだとは思うが
外周で範囲が限定される分マシではあるか
メディアキャッシュの溢れが発生したらそれどころでは無いと思うが
まあ、発生しない前提なんだろうね メディアキャッシュではシーケンシャルで書いてるでしょ？
実際にベンチではランダムライトが異常に早い結果が出る場合も有るし。 >>439
マルチアクチュエーターとバッファNAND
つければ実用のスピード出そうだが。
CMR3,5インチで16TB
MAMR HAMRで18TB 20TBが来年でる今
本当にいるのか？
金型作るのも強トルクモーターも金がいる
Googleが資金だして共同開発するなら
目処ありそうだが 5インチ作るくらいなら厚さ2倍のドライブ作ったほうが良いんじゃないか？
スピンナップにさえ気をつければ特に技術革新不要な気がするし サーバー的には容積辺りの発熱と容量が大切なんだよな。
だからSSDがシェア増えてきてる。
なんせ土地代に比べればユニットコストなんて安いでしょ。 >>446
土地代、電気代、空冷代
故障時の交換要員
全部コストだもんな だからといって数百TBクラスのストレージ構成するのにSSDは現実的じゃないでしょう。
SMRにしろそれ以降にしろ、HDDがねらえるのはもうそこしか無いだけど >>448
どのような手段が安くつくかは、思い込みで考えずに一つ一つ数えていかないとわからないよ。
機械だけが安くついても、維持費がかかってしまう場合もある。
モノは持つだけで維持費がかかるから。特に都会なら場所代 >>443
そんなわけなくね
少なくともファイル1個書くのに内容以外にHDD内のファイルとアドレス管理してる部分も
書き換え無ければならないはずだからファイル毎にシーケンシャルは途切れるはずでしょ
異常に早いのは揮発のキャッシュメモリ使われた場合じゃね？ >>449
数百万はする100TBクラスのSSDって売れてるのかね？
発売されたーみたいなニュースは目にするけれど
採用されたって話はあまり聞かない。
その筋の業界では立派に存在感を示しているんだろうか？ >>450
ファイル毎にシーケンシャルが途切れるからhddに対してランダムライト的な要求が発行される。
hdd側はそれをメディアキャッシュにシーケンシャルで書き込んでいく。
だから、一定量までのランダムライトがちょっと低性能なssdくらいの性能に見える。 >>453
よくわからんがファイル書き込み毎にHDD内のアドレス情報を書き換えずに後回しにするなら安全性が死ぬだろ
アドレス情報書き換えを後回しにした間に瞬電起きたら複数ファイルが死ぬからな
ファイル毎に書き換えるなら当然シーケンシャルな書き込みにはならない
ファイルとは関係無い場所を書き換える事になるだろうから >>454
すまん、話がかみ合ってないな？
osがhddに対してlbaアドレスのn番地からxxxデータを書き込んでくれとコマンドが来るだろ？
hddはメディアキャッシュにそのアドレスとセクタデータをシーケンシャルに書き込む。
暇な時にメディアキャッシュから本来のアドレスに書き直す。
細かい動作に異論はあるだろうけど、だいたいこんな感じじゃないの？
ランダムライトでもメディアキャッシュに余裕がある間はシーケンシャルになるという話だよ。 >>454
補足すると、メディアキャッシュはosから見えるlbaアドレスとは切り離された領域にあるんだと思うよ。 >>455
その方式だとメディアキャッシュにあるデータをosから読めなくね？ >>458
メディアキャッシュにあるデータが本来の場所に書き直されてクリアされるまでは、本来の場所の読み込みはメディアキャッシュから読まれる仕組みとしか考えられない。
また、メディアキャッシュも管理している領域があるだろうから、細かく言えば完全なシーケンシャルアクセスにはならないから、
その事を言ってるのかな？とも思った。
他の人がシーケンシャルと言ってるのも、その点もわかった上でほぼシーケンシャルと言っているのかと。 メディアキャッシュのセクタ代替データをどこに記録してるかって話かな？
ランダムアクセスのそれぞれの代替情報をディスク上に記録してるのなら
それをいちいち書き換えに行くからシーケンシャルにならないと。
ディスク上に記録してたらすべてのアクセスでセクター代替テーブルを参照してからデータを読みに行くことになるし、
突然の中断に対応するという意味でもディスク上ではないように自分は思うけれど。
もしくはセクター情報までまとめてシーケンシャルで書き込んでからDRAM内に参照用に変換テーブルを展開するとかでもいけるか。 >>460
俺もちょっと思ったけど、そこまて厳密な話は出来ないかな。
全て断片的な情報からの予想に過ぎないから。 SMR関連は殆ど情報出てないしね。
今後のTDMRに繋がる技術でもあるし、
実績を積み重ねてアルゴリズムを進化させてる段階だろうしで
SMRってだけの情報じゃかえって混乱する場合もありそうだしね。
SSDのコントローラは論理アドレスとの変換テーブルはどこに持ってるんだろうか？ >>456
OSからはLBAでしか触れない
つまりキャッシュにデータが乗ってる間はLBAと不分離
でないとキャッシュにならないよ >>463
大丈夫、
もちろん、そのつもりで書いてる。 >>459
だからlbaだろうがなんだろうが書き込んだファイルがメディアキャッシュ上の
とあるアドレスにあるって事をファイル書き込み毎にHDDに書かないとosからアクセス出来なくなるでしょ
それを書くって事はシーケンシャルライトにはならんわけで
それを書かないとメディアキャッシュ上のファイルにosからアクセス出来ないから
HDDにファイルを書き込んだ瞬間osから見えなくなるという怪奇現象が発生するぞ >>464
つまり、切り離された領域（物理）って事？
そんで、>>454 は間違ってるんだから補足してどうすんの？
まず454の誤解を訂正しなきゃ シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
シーケンシャルライトの途中で瞬電してもその単体ファイルが死ぬだけで
これはSMR限らず同じことで
普通のならNTFSのファイルテーブルを更新して
SMRのメディアキャッシュに書くならメディアキャッシュ含めたファイルテーブル的なものを更新
だからSMRであってもなくても連続したエリアに書き込む場合であっても
複数のファイルであればシーケンシャルライトにならないってことでしょ？
リードの場合はファイルテーブルを更新しなくていいからシーケンシャルになる >>465
だから、そう書いてるでしょ。
>>466
メディアキャッシュに限らずキャッシュてそういうもんだよ。
通常のアドレス空間から切り離された領域にあってキャッシュしている時だけそのアドレスの代替としてアクセスされる。
一定のアドレスを持っているわけではない。
それくらいは前提として共通認識と思って話してたんだけど、、、 メディアキャッシュの内部の管理方法は外からじゃ判断付かないし答えなんて出ないんでは？
この話発端としていえば、
メディアキャッシュ機能自体がランダムライトの改善効果があるとHGSTは公言していること。
2倍とか3倍のスケールで改善しているってことなんだし、
例え管理領域へのアクセスがあるのだとしても結果として改善効果がということ。
コレがもしDRAMキャッシュ由来の効果なのだとしたら、
同レベルのDRAMキャッシュサイズ持ちのドライブでも同等の改善効果があるはず。 ファイルテーブルも異ファイルもメディアキャッシュに乗せてシーケンシャルすんだよ
吐き出しはあとあと >>469
全くその通りで、思いつく常識的な範囲での想像でしかない。 ありゃ、Wi-Fi切れてスマホのキャリアから書いてた
>>468
何周遅れしてんのよ
ファームウェアすらメディアに載せてんのに
ファイルテーブルも異ファイルもメディアキャッシュに乗せてシーケンシャルすんだよ
吐き出しはあとあと >>469
ランダムライトであってもメディアキャッシュ部は外周部分を使うので
メディアキャッシュに書き込むファイルテーブル部と実データを書き込むメディアキャッシュ部が近いので、
またそもそも外周部のほうが書き込みスピードが速いので速い
よってアイドル時にメディアキャッシュから再記録することを除外すれば速いのは確か
>>470
位置を書き込むファイルテーブルをランダムに書いてたらそのファイルテーブル読めないじゃん
なにいってんのさ ファイルテーブルも実データも、ファイルシステムとしてOSが管理区別している
ファームウェア側からはうかがい知れないよ アンカーつけないと気が付かないかも
>>473
>>474 を読んでね そういや、ファーム側から見てるのかOS側からなのか、区別つけないで論じてる人が前にもいたな >>474
フォーマットのファイルテーブルとSMRのファイルテーブルは当然別 >>478
何から見てじゃないでしょ
人間が外から見てだよ ■ このスレッドは過去ログ倉庫に格納されています
