X



【瓦記録】SMRのHDD 4台目【プラッタ枚数減】
■ このスレッドは過去ログ倉庫に格納されています
0001Socket774 (ワッチョイ 0fdc-RM76)
垢版 |
2019/01/03(木) 22:23:42.35ID:kjJLg9Lg0
!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
0108Socket774 (ワッチョイ 19dc-Fjw0)
垢版 |
2019/01/11(金) 22:56:03.99ID:7XrZ8U/K0
ベンチマークやっても実際のSMR領域ではなくメディアキャッシュ領域の結果が出るから意味ないんだよなこれが
0110Socket774 (ワッチョイ 7158-VK1S)
垢版 |
2019/01/11(金) 23:12:04.57ID:+dEd5T0/0
>>99
瓦と非瓦とまぜてバックアップするのはいいかもな。
通常使用は瓦で徐々にデータを貯めていき、一括バックアップのときは非瓦に。
瓦をバックアップに使うときはリアルタイムバックアップで。
これでデータが3セットできるからだいたい大丈夫だろう。
0111Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/11(金) 23:42:21.54ID:8eskX1jf0
>>108
そうね。SMRはランダム書き込みが遅いとかいう風説は小さな勘違いがあるんだよなあ。
アレは実はメディアキャッシュのフラッシュ方式の遅速の問題に過ぎず、
SMRの瓦バンドそれ自体のデータ転送能力のことじゃないんだよね〜

Seagate disks are known to clean during idle times and to have static mapping [1].
Therefore, they have high throughput while the persistent cache is not full, and ultra-low
throughput after it fills. The difference in the time when the throughput drops suggests that
the persistent cache size varies among the disks. Western Digital disks, on the other hand, are
likely to clean constantly and have dynamic mapping [9]. Therefore, they have lower throughput
than Seagate disks while the persistent cache is not full, but higher throughput after it fills.

https://www.usenix.org/system/files/conference/fast17/fast17-aghayev.pdf

海門のメディアキャッシュは静的マッピングで、フラッシュはアイドル時なのでランダム書き込みは
キャッシュがオーバーフローする迄は高速。オーバフロー後は劇遅い。
対してWDのメディアキャッシュはダイナミックマッピングでフラッシュは随時。ホストPCが連続書き込み
sている場合でも随時瓦バンドに吐き出し続けるので海門比較では通常時の書き込み速度は遅い。
しかしオーバーフロー後でも劇遅にはならない。

ちなみに、ST8000AS0002の瓦バンドサイズは30MBメディアキャッシュはおよそ25GB。
0113Socket774 (ワッチョイ 4d02-V02Z)
垢版 |
2019/01/12(土) 00:05:50.58ID:CbLdf4xs0
>>102
4に関しては初期のSMRのドライブでないなら、小さなファイルの大量書き込みを避ける。(初期のSMRドライブは何でもメディアキャッシュに書き込むドライブもあるらしい。そういうドライブは工夫でどうにもならんと思う。)

具体的には圧縮ソフトでも使って、大きな一ファイルにしてしまえば良い。
圧縮ソフトのtempフォルダをSMRドライブ以外に設定する。(圧縮済みファイルを編集する時)
0114Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/12(土) 01:12:28.48ID:1/u9JrsL0
今日のテスト結果

今回はWin10 PCでやりました。

[3] CDMによるベンチ測定

OS:Windows 10 pro 64bit

SMR IOデータ製外付けHDD(ドライブ:ST4000DM004)

テストサイズ 50MiB
Seq.Write 118MB/s (ばらつきが大きい)

テストサイズ 1GiB
Seq.Write 174MB/s


CMR WD青6TB(HDDケースで外付け)

テストサイズ 50MiB
Seq.Write 258MB/s

テストサイズ 1GiB
Seq.Write 158MB/s


CMRのテストサイズ50MiBで、Seq.Write 258MB/sという結果が出たけどこれは何?
これがWin10の力?
0115Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/12(土) 01:13:27.33ID:1/u9JrsL0
[4] Fastcopyで121GBのデータのコピー実施

OS:Windows 10 pro 64bit
ソース:約20MBのファイルがおよそ6200個 合計121GB

Fastcopyで121GBのデータのコピー実施
Buffer 256MB

SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ:ST4000DM004)

転送速度 99MiB/s
所要時間 21min00sec


SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)

転送速度 122MiB/s
所要時間 17min04sec

Win7での結果に比べると、SMRは所要時間が短くなったけど、CMRは逆に長くなっちゃった。
0116Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/12(土) 01:31:08.60ID:1/u9JrsL0
今、Win10 PCを使って、Fastcopyで121GBのデータのコピー(対 CMR)を、コピーツールを使わずに
標準のコピーで実効中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。

Win10 PCで対CMR HDDならコピーツール不要ってことか。
テストサイズ50MiBでSeq.Write 258MB/sという値は伊達じゃないってわけか。
対SMR HDDだとどうなんだろう?
0117Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/12(土) 02:08:17.06ID:1/u9JrsL0
[5] OS標準コピーでの121GBのデータ(XQD)のコピーの所要時間

OS:Windows 10 pro 64bit
ソース:約20MBのファイルがおよそ6200個 合計121GB

SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ:ST4000DM004)

転送速度 100MB/s
所要時間 19min50sec(1190sec)


SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)

転送速度 150MB/s
所要時間 13min35sec(815sec)


Win10では、SMRもCMRもOS標準のコピーを使った方がFastcopyを使うよりも速かった。
またWin7でFastcopyやマッハCopyを使った場合よりも速かった。
結果的に、この作業を行うには、Win10でOS標準のコピーを使うのが一番速い。
ただSMRとCMRでは依然として差はあって、SMRの方が1.46倍時間がかかる。
問題はこのSMRとCMRの差ですね。
あとはディスクの内周まで書き込みが進んだ場合にどういう挙動になるかですね。
0118Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/12(土) 02:17:53.71ID:1/u9JrsL0
>>116
> 今、Win10 PCを使って、Fastcopyで121GBのデータのコピー(対 CMR)を、コピーツールを使わずに
> 標準のコピーで実効中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。

コピペで日本語がおかしいので、訂正。

今、Win10 PCを使って、121GBのデータのコピー(対 CMR)を、コピーツールを使わずに標準のコピー
で実行中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。
0123Socket774 (ワッチョイ 7acd-WxSg)
垢版 |
2019/01/12(土) 07:46:05.78ID:FAfwqMdN0
fastcopyのバッファを変化させたデータも取ったほうがいいんじゃ?

256MBを32MBに落とすとか512MBにするとか
0132Socket774 (スププ Sd9a-qBIH)
垢版 |
2019/01/13(日) 14:58:01.64ID:0XgU6uRJd
>>106
>HDD上の空き断片に遭遇したり
これが問題なんだよなぁ。使い込むに従って断片は増えていくわけで。

あれ?メディアキャシュフラッシュする時って、以下のどっち?
1.可能な限りブロックそのまま吐き出す
→シーケンシャルに吐き出せる。そのブロックが本来の場所になるようにする。
2.本来書くべき場所に吐く→吐き出し時にランダムアクセス多発?

1だと断片化がえげつなくなりそうだし、2だと、フラッシュが長くなる&空き容量が減ると恐ろしや。

もっと上手くやる手段があると信じてるが…
0137Socket774 (ワッチョイ 8162-iYN/)
垢版 |
2019/01/13(日) 18:50:56.02ID:0h98pHID0
            〃´⌒ヽ
     ., -――  メ/_´⌒ヽ
   /   / ̄  ´ヽ ヽ
  ./  ,  /// ト. !  、 丶ヽ
  l  / /(((リ从  リノ)) '
  |  i  l   . ヽノ .V l
  l ,=!  l  ///    ///l l    ねんがんの14TBをてにいれたぞ!
  l ヾ! ', l    ヽ_フ   l l
  |  ヽヽヽ        //
  l    ヾ≧ , __ , イ〃
  li   (´`)l {ニ0ニ}、 |_"___
  li   /l, l└ タl」/|  HDD  |
  リヽ/ l l__ ./  |_____|
   ,/  L__[]っ / ( ⌒ ) /




::::::::/           ヽ、   :: ::: ::: :::::::::::::::::::::::::::::::::
:::::/            lハ ::: : :: :::::::::: :::::::::::::::::::::::::::::
::::l           l  /ノリ ::: : :: ::::::::::: ::::::::::::::::::::::::
:::|          /) / ::: : :: ::::::::: :::::::::::::::::::::::::::::
::l          /イ/| . :. :. .:: : :: :: :::::::: : ::::::::::::::::
/          / ||/ / ̄ ̄ ̄ ̄ ̄7l:::::::::::::::::::
      i   /_,/i! /⌒⌒⌒⌒⌒/ ,l::::::::::::::::
      l    人   /⌒⌒⌒⌒⌒/ /::::::::::::::::
     l   / /⌒ヽ⌒⌒⌒⌒⌒/ /::::::::::::::::
     l  /il  |   ) ⌒⌒⌒⌒/ /::::::::::::::::
     ll l i! `ー、\_____/n/::::::::::::::::
     lヽ l    |\. \   /⌒〉::::::::::::::::
0138Socket774 (アウアウイー Sa45-RRmW)
垢版 |
2019/01/13(日) 19:05:26.61ID:IcNkJVOGa
ええええええIronWolf4TB買っちまったよおい
SMRなのか!!!!!!ぎゃああえいういのりま」るそらこやそこたねふこえかとゆそほ
0143Socket774 (ワッチョイ e5b1-PC5R)
垢版 |
2019/01/13(日) 19:47:03.02ID:QlShJoM30
本当にうざいわ
HDD買う時にイチイチSMRかどうか確認すんのメンドウなんだよ
しかも開示してないから分からねーし
0145Socket774 (ワッチョイ 4dbe-03VH)
垢版 |
2019/01/13(日) 20:04:01.92ID:qb5pflWX0
古いモデルをまだ売ってるうちに買い溜めしておけってことなのかね

WD青6TBぽちぽちぽちぽちぽちぽち……
0146Socket774 (ワッチョイ d6d5-SD/a)
垢版 |
2019/01/13(日) 20:11:20.35ID:UWGZ0NUj0
>>140
…と思ったが、確定的な情報じゃなかったわ
すまん

ちなみにSMRと断言してるレビューが幾つかあったのは確認してる
0148Socket774 (スプッッ Sd7a-igeR)
垢版 |
2019/01/13(日) 21:57:42.03ID:7gXE92A/d
キャッシュ容量が128とか256だからSMRってわけじゃないぞ?
最近の大容量モデルはキャッシュ増やす傾向

だから余計わかりにくい
0149Socket774 (ワッチョイ d6d5-SD/a)
垢版 |
2019/01/13(日) 22:08:08.37ID:UWGZ0NUj0
…かもしれない

8Tと10Tで挙動が違うのは事実(他のモデルは不明)
8Tに大容量連続書き込みを行うと、例のArchive HDDと同じ挙動(メディアキャッシュ搭載だと同じになるかも?)
ただし、10Tでは速度低下は起きない(これがよく分からないが10TがCMRなのは確定してる)

なので、現状は鉄狼の8Tはあやしいとしか言えないか…
0150Socket774 (ワッチョイ 4d76-J1OY)
垢版 |
2019/01/13(日) 22:42:35.97ID:uzEN83j00
キャッシュだけで判断するのは愚かだと昔から言われてんだろ
CMRのIronwolfもプラッタ上にメディアキャッシュは搭載されてる
メディアキャッシュに書き込んでるときの速度と比較して多少遅いくらいならSMRじゃないと思うが
速度低下とやらがどれくらいの値なのかを教えてほしい
0151Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/13(日) 23:09:39.16ID:mCncWGY80
>>132
> 使い込むに従って断片は増えていくわけで。

この正月休みに、ノートPCにつなげてある外付HDDを10台を全台デフラグしたんだが
デフラグはするもんだなあ。Windows 10のエクスプローラで外付間のファイルコピーのほとんどが
110MB/s 以上コンスタントに出るようになった。コピー後の生成ファイルの99%が断片ゼロ。
使用率99%51GBや使用率95%の8TBのAS0002やかつて断片60万個以上あった4000DM002でも。

Windows10のエクスプローラはファイルコピーの際に、可能な限り断片を作らないように空き地を
確保するファイルアロケーションで実行動作している。ある糞ツールは5GBのファイル1個生成する際
2万個以上の断片をオニギリして吐き出すにだが、そんなボロボロなファイルでさえエクスプローラは
フラグメント・ロンダリング、断片洗浄してキレイなファイルを精製するのよ。だからファイルコピーで
ディスク整理を頻繁に行なっても、実は断片は殆ど増えない。というのが俺の実感。
0152Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/13(日) 23:30:37.69ID:mCncWGY80
> あれ?メディアキャシュフラッシュする時って、以下のどっち?
> 1.可能な限りブロックそのまま吐き出す
> →シーケンシャルに吐き出せる。そのブロックが本来の場所になるようにする。
> 2.本来書くべき場所に吐く→吐き出し時にランダムアクセス多発?

これは 2 でしょ。あるデータブロックをどこに配置保存するかを決めるのはOSの仕事で
HDDのファームが勝手に恣意的に行う事はない。あるファイルがどこにどのように保存
されてあるかというファイル配置(ディレクトリ)情報は NTFSならHDDの外縁部の12.5%を占める
MFTに記録される。HDDがそれを自己都合で任意に書き換えたりはしない。だから、
フラッシュを行う際には大量のヘッドシークを伴うランダムカキコになるはずですね。

ただし、メディアキャッシュの在り処がHDDの最外縁部にありディレクトリ情報保存のMTFと
隣接しているためディレクトリ情報更新のヘッドシークは最小限になるはず。また最近の
WindowsはランダムアクセスをWindows自体の内部処理としてオンメモリで処理して、HDDの
ヘッドを省力するようなキャッシングをサポートしているので、処理の軽重はアプリ次第で
改善の余地はあるらしい。
0153Socket774 (ワッチョイ d682-SQZF)
垢版 |
2019/01/14(月) 01:23:12.71ID:BdmLgDrd0
>>150
鉄狼8Tのamazonや価格のレビュー見たら分かるが、100G超えの書き込みで三分の一以下に落ちるらしい

これをどう判断するか…
0155Socket774 (ワッチョイ 817e-03VH)
垢版 |
2019/01/14(月) 03:05:19.86ID:PFMZNZTl0
>>153
うちはなんともない
つーか筐体見たら8TBは6プラであることはすぐに分かる
これをわざわざSMRにする理由が無い
ガセネタを広めるのはやめろ
0157Socket774 (ワッチョイ 558a-kZrb)
垢版 |
2019/01/14(月) 08:17:26.00ID:E33eCdxy0
メディアキャッシュ領域とディスク内周のランダムライトなら3分の一くらい普通にありそうだけど・・・
0158Socket774 (ワッチョイ c1c1-6hes)
垢版 |
2019/01/14(月) 10:53:45.96ID:MPo46kE90
シーケンシャルでも最外周と最内周で2倍違うのとか知らないじゃね
価格の情弱レビューだし
0159Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/14(月) 11:33:28.96ID:Dgy/51P50
>>153
4000DM004の ultra-low throughput after it fills は1/3なんて生易しいもんじゃないよ。
1/100〜1/200以上。 120MB/s〜 が 500KB/s 〜 2MB/sに落ちるし。

1/3 程度、つまり 30〜50MB/s 程度で速度低下が収まっているのであれば、それは普通の現象。
コピー元のソースファイルの断片化が禿げし過ぎる場合はCMR/SMRに関係なく普通に生じる。
断片サイズが200〜400KB以下の場合、5GBのファイルが万単位の断片断片のおにぎりの場合、
コピー速度は40MB/sを下回ることが多い。断片の数だけ読み出し時にヘッドシーク動作が挿入
されるからコピー速度が劇遅になるのは当然。CMRもSMRも同様。

対策としては、断片大量含量ファイル生成時に他ドライブへコピーするとかオンドライブでデフラグ。
或いはファイル整理時にエクスプローラで低速承知でコピーするとかで、断片洗浄する。
洗浄後無断片になれば、50-100MB以上のサイズがあればSMRで100MB/sを下回ることはほぼなくなる。
0160Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/14(月) 12:09:08.29ID:Dgy/51P50
断片含有ファイルの断片洗浄ツールとしてみるとエクスプローラは優秀だと思う。
万単位の断片を含む糞ファイルでさえ断片洗浄し無断片な一本ファイルを精製する。

それに対して、Windows10のアップデーターは糞の類。Cドライブをデフラグした時
テンポラリ名を持つシステムファイル4本がシステムファイルであるがゆえに
書き換え拒否されデフラグ不能。それらはアップデートのたびにドライバーなどを結合統合した
起動イメージのスナップであろう。が数十以上の断片で構成。起動を遅くする原因を
Windows自らアップデート度に作っている。ように見える。
0161Socket774 (ワッチョイ 4d76-J1OY)
垢版 |
2019/01/14(月) 14:29:02.89ID:1+d0prsG0
>>153
3分の1なら30MB/s,40MB/sとかか
SMRなら0MB/sまで落ちても不思議ではないので、CMRだろ
1.33TB×6枚プラッタだろうし、100GBとか移動したならおそらくメディアキャッシュ切れで速度低下したんだと思うけど
知ったかぶりが、速度低下したからSMRだ!とか書いてるだけだろ
0168Socket774 (ワッチョイ 0acf-VK1S)
垢版 |
2019/01/14(月) 23:08:24.57ID:t3Q5UafW0
SMRの8TBとか一気に書き込むとどれくらい時間かかるんだろ
東芝8TBのCMRでもだいぶかかったけどそれの2-3倍かー
0172Socket774 (スププ Sd9a-qBIH)
垢版 |
2019/01/15(火) 08:41:24.57ID:qxbah98zd
>>152
メディアキャシュの時点で本来の場所以外に1クッション噛ませる仕組みがあるからとも考えたけど、やっぱり普通に考えて2だよなぁ

って事はフラッシュ時にあっちこっちのSMRブロックの読み書きが必要って事で…フラッシュ終了の期待時間ってどのぐらいなんだ?

メーカーはフラッシュのシミュレートデータ持ってるハズだから出してほしい…SMRすら言わないんだから無理かww
0174Socket774 (スップ Sd9a-DvuF)
垢版 |
2019/01/15(火) 18:24:59.09ID:rXdORPQld
読み出しヘッダーと書き込みヘッダーを少しずらして配置して、
少し先を読み出しながら書き込むようにすればメディアキャッシュは不要なんじゃないかな?

ブロック内のちょっとした書き換えでも、SMRブロックを丸々一つ分書き込まないといけないのは変わらないけど。
0175Socket774 (ワッチョイ 9505-kZrb)
垢版 |
2019/01/15(火) 19:57:55.71ID:QuHRXqWN0
HDDの大容量化に合わせてアロケーションユニットサイズも大きくすべきだろうが、
そうなるとクラスタギャップ分の損失がどれだけ出れるだろうか……
を知りたくて、それをシミュレートするためのツールを自作したっけ
0177Socket774 (ワッチョイ a673-kZrb)
垢版 |
2019/01/15(火) 21:27:14.25ID:pnEvSQiX0
>>174
昔の3ヘッドのカセットレコーダーのようだ
0178Socket774 (ワッチョイ 3dbe-Fjw0)
垢版 |
2019/01/15(火) 22:19:31.28ID:wQVEyYam0
IDENTIFY_DEVICE WORD 69の下位2bitにSMRに関する情報があるけど正直に申告する必要はないらしく、
いくつか調べたけど東芝 MQ04UBD200(MQ04ABD200のUSB版?)がDevice Managed SMRと宣言されている程度だった

Archive HDD ST8000AS0002 Identify Device 69 0000h (00b)
https://www.seagate.com/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/100757960a.pdf

Archive HDD ST8000AS0022 Identify Device 69 0001h (01b Host Aware)
https://www.seagate.com/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/100795782a.pdf

BarraCuda ST4000DM004 IDENTIFY_DEVICE 69 0000h (00b)
https://crystalmark.info/board/brd/myk/upload/1356_SAS2_2008.txt

WDC WD10SPZX IDENTIFY_DEVICE 69 4D08h (00b)
https://www.reddit.com/r/techsupport/comments/9736f1/in_need_of_help_reading_crystaldiskinfo_results/

TOSHIBA MQ04UBD200 IDENTIFY_DEVICE 69 010Ah (10b Device Managed)
https://crystalmark.info/board/brd/myk/upload/1332_HDTB420AK3AA.txt

https://sourceforge.net/p/smartmontools/mailman/message/35143609/
http://www.t13.org/Documents/UploadedDocuments/docs2016/di529r14-ATAATAPI_Command_Set_-_4.pdf
http://www.t13.org/Documents/UploadedDocuments/docs2015/di537r05-Zoned_Device_ATA_Command_Set_ZAC.pdf
0179Socket774 (ワッチョイ 558a-kZrb)
垢版 |
2019/01/15(火) 22:20:26.26ID:3Y2WfvL70
>>174
SMRブロックサイズ未満のデータを貯めておくところが必要だし、
一部書き換えのデータが連続で来た場合に
SMRブロック更新を順番に行いながらデータ転送を受け入れるような
とても遅いドライブになると思うが。

同時にヘッド動作させるなら読み出したいトラックの位置と書き込みたいトラックの位置それぞれに
微調整しないといけないのにヘッドアーム1つじゃどうしようもない。
0181Socket774 (ワッチョイ 5127-Fjw0)
垢版 |
2019/01/15(火) 23:00:12.37ID:u4Blc4qm0
>>178
----------------------------------------------------------------------------
(2) ST2000LM007-1R8174
----------------------------------------------------------------------------
Model : ST2000LM007-1R8174
Firmware : SBC1
Serial Number : ********
Disk Size : 2000.3 GB (8.4/137.4/2000.3/2000.3)

中略

-- IDENTIFY_DEVICE ---------------------------------------------------------

中略

060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0100
0182Socket774 (スフッ Sd9a-qBIH)
垢版 |
2019/01/16(水) 07:43:30.06ID:lHXQaA8jd
>>179
SMRは本質的に遅いだから、見た目の書き込み速度を稼ぐにはフラッシュ時のペナルティやベリファイのやりにくさを受け入れメディアキャッシュを使用するしかない

JVMのメモリ同様キャッシュは大きければ大きいほど良いのではなく、サイズや吐き出しタイミングのバランス等はメーカーの腕の見せ所で、是非宣伝材料にしてほしいが…

ところでSMRってドレだっけww
0184Socket774 (ワッチョイ a5bc-03VH)
垢版 |
2019/01/16(水) 07:56:58.35ID:GKxzx7Uq0
一般的な家庭用録画機、TVの外付けならスペック的に無問題。
24時間全録な録画用、リニア編集なプロ用とかなら、鉄狼や赤色
みたいなNASスペックが必須かも。
0185Socket774 (ワッチョイ 19bc-VK1S)
垢版 |
2019/01/16(水) 11:04:34.07ID:Io60NgxJ0
シーゲイトのPR記事では複数ストリームの同時記録みたいなことは苦手って言ってなかったっけ?
だからレコーダーの2番組同時記録とかするのならSMRは止めたほうが良い。

乗せるのならAVコマンド対応のドライブ。
WDのAV-GPや紫、東芝の末尾Vシリーズ、シーゲイトのSkyHawkなど
0189Socket774 (アウアウエー Sa22-kZrb)
垢版 |
2019/01/16(水) 13:15:41.92ID:0IRYufg/a
シーゲートの人がSMRは同時録画用途には不向きと記事で言ってたのは見たことある
0191Socket774 (ワッチョイ 19bc-VK1S)
垢版 |
2019/01/16(水) 13:37:18.36ID:Io60NgxJ0
AVコマンド対応ドライブがみんな非SMRなことから考えてみれば、答えは出てると思うけどね。
0192Socket774 (ワッチョイ 19bc-VK1S)
垢版 |
2019/01/16(水) 13:45:46.77ID:Io60NgxJ0
まだSMRを表に出してた頃の記事だけど
https://akiba-pc.watch.impress.co.jp/docs/sp/680650.html
普通のTV録画用として使う分には問題ありませんが、多数のストリームを常時同時に録画する、という用途には向いていないかもしれません。

今の世代のSMRでここが改善されてると思えば使えばいいんじゃないかな。
今のSMRはいろいろと別モノだと思うし改善されてる可能性もあるとは思うけれど、
録画失敗のリスクと価格メリットを考えてどっちを取るかだと思うよ。

自分で判断できないのならテレビやレコのメーカー推奨ドライブ買うしかない。
0193Socket774 (ワッチョイ 9520-V+wx)
垢版 |
2019/01/16(水) 13:49:27.71ID:25aEcIdE0
同時録画はAVコマンドが無いCMRの青でも
うまくいかなかったりするよ
SMRの方が遅いなら難しいんじゃね
0195Socket774 (ワッチョイ e565-SD/a)
垢版 |
2019/01/16(水) 16:42:23.28ID:JhRto4dt0
>>194
1時間録画してインターバルが数時間ある。そして2〜3番組録画をしないって条件ならSMR処理が間に合いそうだけど、
そんな気を使うレコーダーなんてイヤだw
0196Socket774 (ワッチョイ a57c-UBdn)
垢版 |
2019/01/16(水) 18:10:29.62ID:CpWGPQaq0
>>192
その記事は5年前のだね。

海門の正規代理店やってるエレコムがパッケージングして量販店に出している4TB、
初期ロットはDM005だったが最近のはDM004に変更されている。どっちも録画用で
4K、スターチャネル録画などで使用している。2番組同時録画もするが無問題ね。
最近のregza は6TBサポートが公式。当然SMR HDD 対応でしょうねえ。

Seagate 3年保証 4TB TV 録画 外付 HDD 4K テレビ PS4 対応 静音 ハードディスク 3.5 インチ USB3.0 シーゲイト 日本正規代理店品 安心コールサポートあり
https://www.amazon.co.jp//dp/B07FN69HLW
0197Socket774 (ワッチョイ 8e11-pDoG)
垢版 |
2019/01/16(水) 20:18:55.98ID:O7BA1YDB0
>>183
ドライブ側の遅延でリアルタイム録画の書き込みが追いつかなくなった場合に、レコーダー側がどう対処反応するかが不明
録画を停止するか、壊れるか

一度内蔵HDDにでも録画した番組を外付けSMRHDDへダビングして保管するなら、リアルタイム性は要求されないので問題ないように思われる
0198Socket774 (ワッチョイ 8e11-pDoG)
垢版 |
2019/01/16(水) 20:22:13.31ID:O7BA1YDB0
>>186
あのPR記事は、たったの24時間の録画しか検証してないから
まだ容量が膨大にたくさん残ってる状態で検証しても、SMRドライブの動作傾向を知るのになんの参考にもならない
0203Socket774 (ワッチョイ 8e11-pDoG)
垢版 |
2019/01/16(水) 21:40:43.99ID:O7BA1YDB0
>>200
膨大な連続空き領域が残っている状態での検証で、フラグメントが分散している状態で発生するSMR特有の挙動が解かるわけないだろ
0207Socket774 (オッペケ Sr85-PC5R)
垢版 |
2019/01/16(水) 22:11:48.20ID:/ax7o/2Tr
>>205
ドライブマネージメントってそういうものでしょ。ホストマネージメントなら勝手に動きはしないけど。
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況