【瓦記録】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 7以上のOSでフォーマットしてから持ってくれば一応ズレは直る
でも2Tまでしか使えないならSMR使う意味ないな SMRのブロックって256MBで確定なのか？
個人のブログ程度のソースしか見当たらなかったけど
ただ機構を考えるとキャッシュ目一杯のそのサイズで考えるのが妥当とも思えるが 普通に考えたらトラック単位でバンドブロックがあるだろうし、
トラックくあたりのセクタ数は一定ではない。
つまりバンドブロックサイズも一定ではないと考えるべきじゃね？ キャッシュサイズ目一杯はないと思う
コマンドキューが非順序実行用あるわけだから
リードライト複数ブロックキャッシュに乗らないといけない
ATAコマンドの最大転送量が３２MBなんで３２MBか１６MBか
16MB固定ブロックサイズとして最外周でも5周以上なんで最大ロスが20％全体ロスが10％
32MBなら全体ロスが10％
（シーク用の固定パターン除く） 訂正
誤 32MBなら全体ロスが10％
正 32MBなら全体ロスが5％
補足最大転送速度から１周容量3ＭＢ以下 >>308
1トラックのサイズって最外周でも3MB程度って事か？ >>303
それは昔の認識だね
今はツールでXPでも3TB以上のHDDが使えるよ
というかSeagateも公式ツールでXPに正式対応している
ただ、すべてを一つの領域は無理で、Seagateのは2TB+αに分かれてしまう（HGSTなら一つにできる） 空き容量が1GBぐらいになるまで埋めてからベンチマークすれば、違いが大きく出そうな気がする
買えないからテストできないけど いや俺がSMRのブロックサイズで思ってたのは
SMRのブロックを書く時って必ず瓦の層分のトラックを跨ぐシークが発生するわけだろ
例えば瓦3層1組で構成されてるSMRの場合は1ブロック書くのに必ず2回トラックを跨ぐシークが発生するわけで
そのシークを減らすために巨大なブロックが必要なのかと思ってたんだが
そもそも1トラックが3MB程度しかないなら瓦3層ならブロックは3*3の9MBあれば十分だな
もしかしたらSMRのブロックは書き込むトラックのサイズによって可変だったりする可能性もあるか？
瓦3層で書き込むトラックのサイズが1MBだったらブロックサイズは3MBより大きくある意味無いっしょ
他にブロックサイズを大きくする理由ある？ 螺旋書きだからブロック途中の非連続シークは発生しない
有効トラックがあるのは半径方向のせいぜい１/２まで
308で考慮し忘れたが重ねた部分はトラック密度が上がる >>316-317
螺旋でも隣り合った同心円でもバッファ働くから大差ないのでは >>318
書き込み遅すぎ
これはなんていうベンチ？ >>318
同じベンチをCMRの8TBにしたデータ無いですか？ >>318
ついでに同じベンチを8TBのSSDで行なった比較もきぼんぬ >>319
いやもしCMRが螺旋書き込みだったらブロック毎の書き込みにトラック移動のシークが
余計に発生するSMRはシーケンシャルライトでも完全劣化になるところだよ >>318
いくら倉庫用とはいっても最初にデータ書き込みする必要はあるわけで・・・
遅すぎでしょ。物売るってレベルじゃないわこれ >>301
そもそもXP使うこと自体に問題があるだろ >>320
Gnome Disks のベンチマーク
>>321
赤玉3Tが同じPCに刺さってるのでこちらを
https://i.imgur.com/Qc1oO0Y.png
>>322
無茶ゆーなｗ
>>324
ベンチはベンチ
通常利用ならきっとキャッシュが効くと思います >>326
ありがとうございます。
容量やメーカーの違いはあるけど、これがCMRとSMRの実力差と思って良いんですかね。 トラックが増えるからプラッタ当たりの密度は増えてるけどトラック密度は変わらんでしょ 書き込みした隣接のトラックも書き込まないといけない
↓
書き込んだ隣接トラックの隣接したトラックも書き込まないといけない
↓
書き込みした隣接のトラックも書き込まないといけない
↓
以下ループで1MB/s 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) シーケンシャルライト時に隣接トラックも書き込み対象にしてしまえば
隣接トラックに書きこむ処理をロスにはならなくできそうだけど
書き込み箇所はOSが決めるからそうは出来ないのかな？ >>331
LinuxのextNとWindowsのNTFSとではファイルの置き場所アロケーションのアルゴの態度が違うよね。
Linuxはアトランダム。NTFSは基本外縁部から連続的詰め込み。
>>326のGNOME DisksはubuntuとかのToolでしょ。Win/NTFS環境下のお話じゃないから窓的には
ちょっと筋が違うかもね。それとSMR@海門のバンドサイズは20〜30MBだということだから(CM大論文)
テストファイルのサイズが10MBは、まあ弱点もろ突きかもねｗ
螺旋書き云々は、ま、書き込みヘッド幅が絶妙微妙なSMRではそんな面倒なヘッドシークしないよね。
螺旋書きを採用している外部記憶といえば旧MacOSのFDDが有名だけど、68KMacのエミュの作り手が
オリジナルFDD読み出しで苦労した点。結局特殊な同期ハードウェアを噛ますほかなかったとか。
あとはCDかな。螺旋読み込みがアクセス速度の頭打ちネックになっていたような。
Understanding the CD: The Spiral
https://electronics.howstuffworks.com/cd2.htm NTFSは1回の書き込みで5、6回書き込みが発生するからSMRと相性悪い
FAT系(exFATなど)で利用すると多少マシになる CDDVDのアクセス速度が遅いのはＣＬＶで回転数可変のため
螺旋配置とは無関係
連続アクセス前提ならスパイク状にシークして安定を待つより
一定微量シフトしつづけるほうが楽よ 微量シークだとトラッキング位置の調整は発生しないの？ いくら探してもSMRが螺旋記録って情報が見つからん。
知ってる人居たら教えてほしい ＷＤ使ってる人に聞きたいんだけど、インテリパークって無効にしてる？ 805 名前：Socket774 (ﾜｯﾁｮｲ df02-AYLp)[sage] 投稿日：2019/02/03(日) 12:52:37.28 ID:3EIz6RBR0 (PC)
WDの中の人と話せる機会があったからSMR化について聞いたら教えてくれたから報告
（プライベートでの内緒話とかじゃないやりとりです）
・2TBのSMRが出ました。4TBや6TBなど青は全部SMR化していくの？
→します。
・青が全部SMR化したあとは、CMRが欲しければ赤や黒を買うしかない？
→青以外もSMR化していきます。
・SMRかどうか判別のため、スペック表とかにSMRと明記された情報はないですか。
→現時点では、型番が「EZAZ」ならSMRで、他に識別できる公開情報はありません。 同業他社を買収して
独占的地位を得た後に
低性能なゴミを強制的に売りつけて
金儲けする
よくある話だね WDのSMRは特に評判を聞かないけれど、
シゲと同等と判断すべきなのか、シゲとは違って普通に使えてると判断して良いのか。 >>334
windowsseverしかフォーマット出来なかった気がするが10のアップデートでなんか変わったの? パーティション切ってテストするとよく分かるキャッシュの効能
内周部でも速度が落ちない 以下、何もかもうろ覚え！
>>335 >>337
螺旋書きは初耳だし怪しんでる
それは置いといてSMRもトラックあたりのセクタ数は光学ディスクのZCAV的な感じだったような
>>341
ここか前のスレにあった
キャッシュの吐き出しがチョロチョロ行われてて、茂よりやや遅いが急な速度低下はないという話 >>332
326のツールは知らんが、sda表示されてるからファイルシステム関係ないんじゃね？
>>315
1Gって何の話なんだか 将来的にはTDMRや多層記録がアシスト記録の次の技術ロードマップになってるし
ブロック書き込みが既定路線なのはわかるんだが、
問題はドライブマネージドのアルゴリズムやホストマネージドの普及展開。
NAS製品向けに安価なホストマネージド製品展開ってのはダメなのかな？ WDのSMRは試してみたいんだけど、さすがに2TBのドライブを今更買う気にならんしなぁ
まだファームの熟成段階なんかね。
6TBが予定に挙がってるようだけど、一気に10TBまで出しちゃえばいいのに。
10TBがTB単価2000円ちょっとで出たらがかなり魅力的なんだけど。
SMRの仕様を我慢してでも導入検討するわ >>332
シャープMZ-1200だったかに採用され、その後ファミコンのディスクシステムに採用された
片面容量64KBでディスク全体のシーケンシャルアクセスオンリーなクイックディスクが
螺旋トラックだった
CDランダム読み出しでのヘッド位置決めが難しいことからもランダムアクセスで螺旋ってのは無いわな >>349
ばっかおめえQDつったらMZ-1500だべ(老害発言 MZ-1500買ったのは倉沢淳美のファンが多かったんだろうな >>350
そうだったorz
700/1200/1500の関係がときどきわからなくなる
モノクロ/カラー/QDでよかったっけ？ 夢が広がるディスクシステム〜♪
>>352
80K2E/1200/700./1500の順な なんか wiki にはSMR領域のデータ更新にはまず対象のSMR領域のデータを
メディアキャッシュに書き出すみたいに書いてあるが
流石にキャッシュメモリの間違いだよな？ >>332
バンドサイズとは？
いやバンドってのが瓦の何層かを一括とするって意味だとすると
サイズも何も無いよなーって気がする
最低書き込み領域（サイズ）って意味だとやっぱりブロックと言ったほうが正しいのではないかと SMR処理ではトラック単位で束ねられるだろうし、
中心からの距離によって容量が変わるはず。
なのでトラックを数本束ねたSMR処理の単位をバンドっていうんじゃないかね。
AS002あたりのSMRの記事だとブロックになってるから、なんか理由があって変えたんじゃないかな。 >>358
処理単位というかwikipedia曰く
全トラックを単一的に瓦として重ねてしまうと一番下の瓦の更新処理の手間が
べらぼーに高くなって使い物にならないので
何層か毎に瓦を区切ったのがバンドらしいので
例えば瓦3層で区切ったSMRなら瓦3層毎にバンドとしたSMRとしか言いようがなく
サイズも何もないのではと >>345
1GBについては>>313に聞いてくれ 「層」をどう受け取っていいのかわからん。
トラックの事？ SMRはバンド単位で一気に書かないといけない
この前提はわかってるよね？
バンドのサイズを越えるデータはバンドサイズ単位でシーケンシャルの判定によってメディアキャシュを使わない書き込みが期待できる
バンドサイズ未満のデータはメディアキャッシュに一旦書かれる。
だからバンドサイズ未満のデータを扱えば扱うほどメディアキャッシュ容量を圧迫し
溢れる事による極端な速度低下までの余裕がなくなってくる。
だからサイズに言及してるんだと思うけれど。 内周と外周で密度が違うから、
1ブロックxxMBとか固定じゃないって事かな？ >>363
だからバンドのサイズってなんぞやと
3トラック毎にバンドするっていったら3トラック毎に重ねないトラックを設定する事により
1つのトラック更新を3トラック以内の書き換えで済ませるようにする事でしょ
バンドサイズとはどこのサイズを指す？ バンドの中の一部データの書き換えにもバンド全体の書き替え(厳密には追記のはず)が必要
3トラックで1バンドなら3トラックの容量がバンドのサイズ
SMRの処理をする上での最低処理単位
だからサイズが重要 >>367
おお、つまりSMRの最小書き込みサイズは書き込み先のトラックサイズに依存した可変長であると
それは説なのか確定事項なのか トラック容量が可変でバンドがトラック単位なら
必然的にそうなる
というだけの話だよ。
SMR関連で明確に公表された仕様情報が殆ど無い中では
比較的素直に導き出される推測だと思うけどね。 追記だと、バンド位置によるサイズ可変と相性悪いな。
同位置で書き換えの方がしっくりくる。 >>369
必然なのは重ねられた部分の更新には重なった部分の更新も必要ってところまでで
トラック単位で行う必然性はないかなと思う
別にトラック容量の半分単位でやっても良いし
トラック容量以上のバンド数の倍数サイズの巨大な固定容量を
キャッシュメモリに積んで更新するルールでも良いかと
もちろんトラック単位の可変長でやっても良いとは思うが実際はどうなってるんだろう >>368
製品によってはアルゴリズムを単純化するためにブロック容量を同一にして
外周側ほど「捨てセクタ」が多くなっていたりしてな
（微妙な位置ずれへの対策として1bitでも書き換えが生じたらブロック全体を全部書き直すものもあったり？）
それが思うほど容量が増えない要因の一つだったり
ノウハウが貯まるにつれてアルゴリズムが改良されて容量可変になっていくとかの可能性も
あくまで空想（妄想） >>372
ブロックが固定長であっても色々難しそうよね
どう区切るんだっつー
トラック容量依存の可変長の方が現実的か？ いや、HDDにシーケンシャルライトという概念がある以上
HDDは一本のテープ媒体のようなものと見なすこともできると考えれば
あまりHDDの構造は気にせずに大きめのサイズでブロックを区切ってしまっても問題ないかな そういや最近のSMRってシーケンシャルライトの時は
メディアキャッシュを使わないようになってるとかどっかで見た気がするんだが
あれって本当なの？
だとするとバンドのリードが発生する分逆に書き出しがかなり遅くなる気がするんだが
もしかしてリードしないで書いてるのかな？ 何にしてもバンドのサイズを気にする意味が有ったという事でいいのかな？
少なくとも検証をするうえで結果に影響があるくらいには意味があると。 >>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のみよりも高速になる。 ■ このスレッドは過去ログ倉庫に格納されています
