【瓦記録】SMRのHDD 8台目【ﾌﾟﾗｯﾀ枚数減】
■ このスレッドは過去ログ倉庫に格納されています
!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 7台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1561881186/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured SMRは1回のみ書きこみ可のでかいCDRとして使えってばっちゃが >>20
SMR ってのは 瓦磁気記録方式 の事で SMR するってのは瓦書きするって事だと思ってたのだが違うのか？ >>20
ああ、そうか多分お前は直書きというのを勘違いしていて
その直書きとは具体的に何をする事かと言うと
「SMR の HDD がメディアキャッシュを経由せずに瓦領域に直にデータを瓦書きする」
って事
だからその6TBは全部瓦書きされてるものなので特に矛盾は無い >>20
SMR ってのは文字通り瓦屋根の瓦のように重ねるデータの書き方をしていて
データを色として例えると1番の問題は
筆が瓦と同じ大きさの物のしか無いので
1番下の瓦の色を変えると1つ上の瓦の色も変わってしまうと
それを回避するには上の瓦の色を別の場所に記憶しといて下の瓦の色を変えた後に元の色で書き直す必要がある
そして上の瓦を書き直すとなるとさらに上の瓦についても同じ対応が必要になる
というのを瓦屋根の最上段までやる必要がある
これがお前の言うSMRするって事だろう
で、SMRのHDDとしても一部のデータ更新の度にHDD全体の
データの更新が発生する可能性があるなんてやってられないので
瓦書きの連鎖が切れるように瓦の領域を分割している
要は HDD 内に複数の瓦屋根を用意している感じだ
ある瓦屋根の瓦の色を変更したって隣の家の瓦屋根の瓦の色には影響しないだろ？
具体的には定期的に重ならないトラックを設定してるって事だが
この瓦屋根1つをバンドと言う
どっかで1バンド30MB位と言ってたのでそれが本当だとすると6TBのSMRだと
20万個位バンドがあるって事だな >>20
バンドを設定したものの1MBのデータを書き込むのに
内部的に30MBもの更新が必要なようでは速さ的に使い物にならない
そこでSMRのHDDの中に瓦状になっていない
つまりCMRと同等の領域を用意し
OSからの書き込み要求のあったものはとりあえずそこに書いてOSには書き込み成功を返し
後でこっそり瓦書きする方針にした
この SMR HDD 内の瓦になっていない不揮発の領域を
メディアキャッシュ（MC）という
HDDによってはMCは20GB程用意されてるという話もあり
瓦書きする際の瓦上の既存のデータの退避にも使われてるという
ここらへん踏まえたら >>18 の説明がわかったりしないかな SMR形式は多段階のキャッシュ(RAMやフラッシュメモリー）とプラッタ上のCMR形式で書かれるメディアキャッシュが使われ、
バンド構造をもって、なるべく重ね書きとそれに伴う処理がユーザーの不利益にならないようになってる仕組みは、このスレの
議論や>>25-26 の説明でだいたい判ってるけども、ホストマネージド型のSMR HDDの場合は、破綻しないようにOS側と
調整されるので、数十分の応答停止とかまず、発生しないと思う。
一般用に販売されているドライブマネージド型のSMR HDDの場合、連続書込なのかランダム書込なのか、RAID制御
されているのかドライブの自己判断に任されているせいか、100MB/秒くらいの書込速度が常に出ていたので空き容量が
2TBくらいあるHDDだから、300GB程度の書込くらいどうって事無いだろうとコピーしたら、なぜか１０分以上応答停止にな
ってしまう。
PCの起動時間中になんらかのSMR処理のバンド処理？が終わってなくて、運悪く、そのあたりに書込が始まってしまったり
する不幸があると応答停止になるのでいつ、そうなるか判らないんです！とかいう仕組みだとしたら、ほんと迷惑。
WDのRedはRAID対応として販売されているので、WDはノーチェックでCMRのラインナップにSMRを混ぜたりしないだろうから
メーカーでも応答停止になる条件が絞り込めてないのかもなーとか思ってます。 >>27
完全な俺の推測だけど
例えば4台のRAID5の場合
シーケンシャルなデータを書き込む時に3台に分割する事（処理）が影響して
その多くがSMRにシーケンシャルライトとして認識されずに
MC送りになってしまうのでは無いかなと RAID5にSMRを使うのが間違い
だが、WD赤もSMR化する時代ｗ >>30
おいおい、遅れてるな
今度はSMRの赤とCMRの赤が出るらしいぜ >>31
遅れてるぞ>>29で言っただろ
もう赤はSMRだ >>32
お前が言ってるのは最新の赤がSMRだったって話だろ
俺が言ってるのは次に出る赤はSMRとCMR同時発売だって話 >>28
WDも様々な台数構成で試したと思うんだけど、リビルドを失敗するから裁判になってるが、
CMRだけで構成したRAID5でもリビルド失敗があるのでどうだろ、7割以上リビルドできないとなれば有罪となるか？
なんとなく、プラッタ上に中途半端にSMR処理を進めた領域がばらついていたりすると応答停止し易い様な気がする。
RAIDの場合、細々とバンド処理をこなす時間が与えられなくて、破綻しやすいとかで。 まあWDが裁判に負けて方式の明記を義務づけられれば
みんな買う前にわかって平和になるってこった WDC WD60EZAZ(SMRドライブ)ですけどー、
=================================================
FastCopy(ver3.90) start at 2020/06/26 20:39:41
<Source> J:\Video\その他
<Command> 全削除 (with)
-------------------------------------------------
Aborted by User
TotalDel = 189,933 MiB
DelFiles = 64 (0)
TotalTime = 01:12:36
FileRate = 0.01 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2020/06/26 21:52:18
最後の8GBの1ファイルを消すのに１時間経っても終わらないので強制終了したり。
ちなみにエクスプローラーで、なかなか消えなかった1ファイルを削除しようとDELすると応答停止しますw
SMR処理が終わらないんでしょうね。
数ヶ月使って、7割ほど使用したSMRドライブは、200GBほどのコピーや削除で応答停止になりやすくなって
ほんと使いづらくなったなーって。
光学メディアじゃ無いけど、ファイルを追記するだけで削除とか余計なことしないでディスクフルになるまで
使うのがSMRドライブとして健康なのかもしれませんw なかなか不思議な現象だな
8GBのファイル消すって言っても8GBゼロフィルするわけでも無いだろうし
ファイルシステムが壊れてるんじゃないか？
それともMFTがSMRに向かない形状になって行くのだろうか 断片化が進んでたら8GB消すときに実際は何十GBも道連れに消して、道連れを全部書き戻す
というのをやらないといけないからな
道連れの容量がMCの容量を上回っているととても悲惨なことに >>40
普通のOSでの削除はファイルアロケーションテーブルを書き換えるだけで実データがあるエリアは触らんでしょ。
Fastcopyで特殊な削除してんじゃないの？ 元々、その他フォルダ(約190GB)が不要になったのでFastcopyで削除を始めたわけです。
普通だったら、１分程度で削除終了するんだけど１時間オーバーしても終わらず、
その他フォルダを開けてみると1ファイル8GBがしぶとく残ってたという状況。
念のため、Fastcopyを強制終了後にチェックディスクしてみても特に問題なし。
>>40
なんか、そんな処理が大量に発生するんでしょうね。
>>41
Fastcopyに問題が出たら、公式フォーラムに苦情書き込み殺到するはず。ユーザーも相当数いますし。
SMRドライブ以外に使うと異常に時間がかかったりしないのです。 あー、もしかしてMFTが断片化してるとやばいのかな？
画像の処理とかでファイル何千個も書いたり消したりするとすぐ断片化するもんね >>43
ちょっと前からネットワーク越しにvvaultで管理してるフォルダにFastcopy使うと、タイムアウト待ちみたいな停止や、vvaultのサービスがフリーズしたりするようになってる。
Win10のアップデート絡みか、Fascopyの更新に依るものかはわかんないけどね。
移動ジョブ積み上げて放置出来るからFastcopy重宝してたんだけど、しばらくは普通にエクスプローラの機能で我慢かな・・・
ver 3.87からVS2019に変えたとの事なのでその辺も影響あるのかな？ってしばらく様子見モード >>43
いやいやいや、HDD上のデータにおいて削除なんてものは無いってのは基本だからな
本当に削除なんてコマンドは無いからアクセス出来なくするか上書きするかしかない
アクセス出来なくするなんてのもOSが勝手にアドレス（多くてKB）忘れるだけ
だからHDD廃棄時の情報漏えいが問題となるわけで >>34
>中途半端にSMR処理を進めた領域
まーそうなんだろうな。だから単純にxx書いても問題なかった！と言われても参考にしかならない。
そんな状態になるのは使い込んでからだし。
低下しにくいWDですら結局破綻したのは正直困った。 HDDはTRIMコマンド使わないよね
つまり
一度全領域の書き込みを行ったらHDDは空きエリアを知る術が無いから
単純な1セクタの書き込みでも
バンド全体のリードモディファイライトが発生する？ ディスク使用量によってダイナミックに
バンドとキャッシュの比率を変えられない
キャッシュにしかないデータは常に減らしておく必要がある
だから1セクタ書くだけで基本的にはバンドのリードモディファイライトする必要がある
たまたま同じバンドのセクタの書き込みが短時間に複数あった場合だけリードモディファイライトをまとめられる
これじゃ性能が糞なのは当たり前だ TRIMに対応すればいいんじゃないの？
当然すでに対応してる？ 申し訳ない。
１つだけなかなか削除されないファイルがあると書いたが、CMRのHDDにも同じがファイルがあってテレビの録画ファイルなので
再生してみると他番組の一部が先頭に混じっていて、数分するとファイル名の番組の内容になる異常なファイルになっていて、
これがFastcopyの削除を妨げていた（スキャンディスクしても特に問題は出てなかったが）。
異常なファイルは右クリックするとエクスプローラーが応答停止して10分くらい反応が無くなる。
で、このファイルはコマンドプロンプトのdelコマンドでも削除できないし、強制削除するフリーウエアでも削除できないから
ubuntuのブータブルUSBを作って、linux上からの削除は問題なく出来たのでWin10の問題なのかもしれない。
異常なファイルの混じってしまった部分を削除し、ファイル名を変えて出力したら普通に再生できたし、SMRドライブに
Fastcopyでのコピーも110MB/秒、削除も一瞬で済んだw
ついでながら、150GBほど適当なファイルをSMRドライブにFastcopyして、Fastcopyの全削除を2回やってみたが、
応答停止にならなかったので、ほんとどういうタイミングで応答停止するか判らなくなった。
ちなみに >>7 で応答停止になったときにコピーしたファイルをチェックしてみたが、今回のような内容が混じったり、
ファイルを右クリックするとエクスプローラーが応答停止になるファイルがなかったので微妙な気分。 >>45
Fstcopy 3.9を使ってますが、今回のような異常なファイルが混じらない限り今まで通りです。
異常なファイルが混じらなければ、Fastcopyの全削除は110GBでも一瞬でした。
どっちかというとエクスプローラーで何万〜何十万ファイルをコピーすると取りこぼしするようになったのはヤバいです。
いつの時点か判りませんが、同僚が新たに購入したノートPCにDocumentフォルダ等を旧ノートPCからUSBメモリーに
エクスプローラーでコピーしているときに途中から速度が落ちたものの終わったのでUSBメモリーのフォルダ内のファイル数を
比較すると少ないんですよw
Fastcopyでコピーし直したら、ちゃんとファイル数が一致してたので。
>>50
うちのWDC WD60EZAZは、Win10の最適化ではソリッドステートドライブ扱いでトリムするようになってます。
どんな処理をしているか判らないけど、だいたい１分程度で終了する感じ。 > WD60EZAZのドライブは、転送速度が0MB/秒のままなのでFastcopyを強制終了して、再起動した。
> 最後の8GBの1ファイルを消すのに１時間経っても終わらないので強制終了したり。
書き込み途中で強制終了を当たり前のごとく常用するオッサンとか w >>52
ああ、妄想SMRやこう思ったとか実体験を伴わないクソの役も立たない書き込みではなく、
WD、Seagate、東芝のSMRドライブ比較を実際に購入して、論文のエビデンスになるようなしっかりした結果を
書き込んでくれるというのですか。助かります。
応答停止や発生したトラブルの8〜9割再現事例をしっかりと教えてください。よろしくお願いします。 >>55
いや、全然参考にならんとかいう次元の話でもなく
結論としてはSMR全然関係無い話だったって事じゃないのか？
そこんとこお前はどう考えてるんだ？ だいたい51とか53みたいなおま環みたいなものをgdgd書かれても読む気にならんわ >>55
言ってしまえば >>51 はスレチでそれに対して
>>52 が参考にならんとレスするおかしな流れになってるだけじゃね
スレチを察せられなかった >>52 が悪いのか
スレチを明示しなかった >>51 が悪いのかわからんが https://www.newtech.co.jp/introduce/hd2/
ではSMR HDDに上述のような特徴があることを理解したうえで、どういった用途であれば比較的問題なく使えるのだろうか。
まずランダムに細かいデータを書き込むようなデータベースやデータの更新が頻繁にあり、
性能を担保したファイルサーバ用途では使うべきではないと断言できる。
一方で連続書き込みをしてまとめて消去するような用途の例えばビデオレコーダや監視カメラの画像保存などであれば
後述する十分な評価や状況を認識した上であれば使えるかもしれない。
また性能劣化が発生するのがSMRの主な問題なので性能にこだわりのないアプリケーションでも問題はない。
SMR HDDの厄介な点は上述のとおり書き換え(上書き)が発生しない限り(例えば使い始めで空き容量に余裕があるとき)は問題が顕在化しない点である。
例えば容量がある程度使われた後に何かを削除した時に問題(性能劣化)が出るのである。
SMR HDDの採用にあたり評価をする際にはこの点に留意しなければならない。
容量が一杯になるまで、また一杯になった後でも書き込まれるデータパターンが本番環境と近しいもので評価をしないと、
いざ使いだして何年か後に性能が著しく劣化するなどという事態に直面するかもしれない。
何れにしてもHDDメーカ毎、さらにはモデル毎にSMRのデータ退避、書き込み方法、データサイズおよび処理タイミングなどが異なるので注意が必要である。
さらに言うなら同じメーカの同じモデルでもファームウエアのバージョンによっても振る舞いが変わる可能性は否定できない。
注)SMR HDD単体であれば性能劣化してもOSからのタイムアウト内に応答できれば応答が遅いだけで済むが、HDD複数台でRAID化した場合は別問題である。
RAIDはその性質上、性能や冗長性を担保するために応答の遅いHDDは切り離すのが一般的だからである。
HDDに何か問題が内在して応答が遅くなっているのか、上書き操作の過程で余計な読み書きが起こって遅いのか、
RAIDコントローラには区別がつかないのである。HDDの応答が遅くても切り離しをしないRAIDコントローラのファームウエアを作ることは容易いが、
問題のあるかもしれないHDDを抱えながらデータを保存し続ける事は大きなリスクである。 >>61
SMRは、NTFSとかWin系のファイルシステムだと問題が起きにくく、バラバラに書いていくMacOS(BSD)やLinux系のファイルシステム
だと煩雑な処理が発生しやすく、同様のRAID5以上もなりやすいと読めるよね。
実際、SMRのHDDをWin10でのイメージバックアップや録画ファイル置き場で使っていると連続書込、まとめて消去が多いので
応答不能になったのは１ファイル自体の異常だった時だけで、デフラグしても異常に時間が掛かったりしなかった。
RAIDを組む必要がまったくないので、RAID5以上でどうなるかは体験してないけど。 素晴らしいまさにこの点が厄介。
これを無視した書き込みのなんと多い事か。
>SMR HDDの厄介な点は上述のとおり書き換え(上書き)が発生しない限り(例えば使い始めで空き容量に余裕があるとき)は問題が顕在化しない点である。
>いざ使いだして何年か後に性能が著しく劣化するなどという事態に直面するかもしれない。 >>63
いやいやいや
根本的な話としてSMRとか関係なくTrim対応ではないHDDの書き込みって全て上書きだろ >>64
SMRだから書き換え時に問題が発生する
CMRでは書き換え時の問題はない >>64
CMRの上書きはその通りただの上書きだけど
SMRの上書きはバンドに含まれるファイルを全部退避して、新しいファイル書いて
退避したファイルを書き戻す、なのでかかる手間が段違い 厳密に言うと
最近のHDDは512バイトセクタ単独で書き込むと
リードモディファイライトが発生する
そんな書き込みをするOSは絶滅したけど >>65
>>66
そういう話ではなく
HDDの構造上書き込みは全部上書き（書き換え）だから
使い始めだろうがなんだろうがSMRの問題は発生するよって事 >>68
trimを使えば
使用量が少ない時はSMRのパフォーマンス上の問題を減らす事が出来る
使ってないバンドならリードの必要もないし
使ってる分だけ書けば良い
ダイナミックにSMR領域を変えることもできる
trimがないとそういうことは出来ない CMR > Trim有りSMR > Trim無しSMR >>66
>>70
× > CMR > Trim有りSMR > Trim無しSMR
○ > CMR or Trim無しSMR ≧ Trim有りSMR
trim有りは WDだけでしょ。trim完了済でどうにか海門並み。 >>71
仮に逆転があったらそれはSMRの制御が洗練されてないってこと
CMR > Trim有りSMR > Trim無しSMR
これは確実
当然だ
Trim無しSMRが性能が悪くないなら
全てこれに置き換わってるはずだ しばらくは、オタ界によくある大した意味が無い「間違い探しと答え合わせ」でスレが消費されますので生暖かい目で見守って下さい。 どっかに SMR の Trim で何やってるかのPDFが貼られてたと思ったが
とりあえず Trim 云々言うならあれ読んどいた方が良いと思うが ついでだからこっちも貼っておく。WDは例の赤SMRについて弁明というか
解説している。特に気になったのは、RAIDで赤SMRの件、社内テストでは
問題なし。と断言している点。論社は懐疑的な評価スタンスだけども。
-----------
Western Digital statement
Shingled magnetic recording (SMR) is a hard drive technology that efficiently
increases areal density and capacity for users managing increasing amounts of data,
thus lowering users’ TCO. There are both device-managed and host-managed types,
each for different use cases.
All our WD Red drives are designed to meet or exceed the performance requirements
and specifications for common and intended small business/home NAS workloads.
WD Red capacities 2TB-6TB currently employ device-managed shingled magnetic
recording (DMSMR) to maximize areal density and capacity. WD Red 8-14TB drives
use conventional magnetic recording (CMR). DMSMR should not be confused with
host-managed SMR (HMSMR), which is designed for data center applications having
respective workload requirements and host integration.
DMSMR is designed to manage intelligent data placement within the drive, rather
than relying on the host, thus enabling a seamless integration for end users.
The data intensity of typical small business/home NAS workloads is intermittent,
leaving sufficient idle time for DMSMR drives to perform background data
management tasks as needed and continue an optimal performance experience for users.
WD Red drives are designed and tested for an annualized workload rate up to 180TB.
Western Digital has seen reports of WD Red use in workloads far exceeding our specs
and recommendations. Should users’ use cases exceed intended workloads,
we recommend WD Red Pro or Ultrastar data center drives. Western Digital works extensively with customers and the NAS vendor and partner
communities to continually optimize our technology and products for common
uses cases. In collaboration with major NAS providers, we work to ensure WD Red HDDs
(and SSDs) at all capacities are compatible with a broad set of host systems.
In our testing of WD Red drives, we have not found RAID rebuild issues
due to DMSMR technology.
Our customers’ experience is important to us. We will continue listening to and
collaborating with the broad customer and partner communities to innovate
technologies that enable better experiences with, more efficient management
of and faster decisions from data.
https://blocksandfiles.com/2020/04/20/western-digital-smr-drives-statement/ 上記サイトの文面に、海門とか総じてSMR-HDDのユーザーが幸せになる方法は
ファイルとかの書き込み1回ごとに10秒間のライティング・ディスタンスを維持して
ゆっくり使うことだ。とか。これは俺も同意。海門SMRの超低速モードは
何度も体験したんで稠密接連続的ファイルカキコ限定ではあえてCMR使っている。
WDのSMRってOS＠ホストがtrim発行する時点でDMじゃなくてHM。ホスト
マネージドと呼べたりして。そういう扱いは英語圏でも見たことないけどさ。 >>78
10秒間待てって本気で言ってるのか！？
MCがあふれる量の書き込みをするのであれば
全部タスクに積んで自動でMCが空いたら書かれるのに任せても
手動でMCが空くのを待って書き込みしても書き込みにかかる総時間は変わらんだろ
むしろ前者の方が早く終わる可能性は高いと思うんだが
10秒間待った方が良いってのはどういう理屈なんだ？ >>75
そのWDの資料だとTrimするにはLinuxではアプリ側のサポートが必要なのでサンプルプログラムが付いているけど、MacOS(BSD)には触れてないし、
WindowsではSSDのTrimがサポートされているWin8以降は大丈夫だろうという意味で省いているのか不明。
Trimも変換テーブルをSSD準拠にしてあり、ガベージコレクション処理を行うが、データが不要かどうかOSに問い合わせて
ドライブ側で勝手に判断しないとか、ゴミデータをまとめて移動させる〜など多様な処理が書いてあるね。
アクセス頻度もファイル数も少ないNASやRAID構成だと自己メンテナンスであるTrimするヒマもあるんだろうけど、CMRより何倍か時間が
掛かる処理をすることもあるので、その処理中に応答速度が下がるからSMRドライブが降格しやすくなるので、NASメーカーなどがSMRを
使用禁止にしたり、推奨しないんだろうなとは読めた。
そういった前提があると、RAID構成がリビルドになった時にSMRドライブ側としては大幅に待ってもらえばリビルド完了できるところ、
応答不能や応答停止と判断されて切り離されるとリビルド不能になってしまう為、配慮が欲しいとか？ >>80
Mac OS XはプロプライエタリだからApple自身が当然サポートしているでしょうね。
Linuxはディストリが無数にあって、あちらのフォーラムでユーザーがSMRダメダメ
レポして開発サイドがレス対応するようなページをいくつか見たことがある。6.xは
ダメ、7.xは微妙、8.xはデフォサポあり。なのかも。
オレ的に問題はVirtualBoxとか仮想系とゲスト。ゲストOSから見た仮想HDDは
LBA指定でアクセスすべきリアルだけれど、ホストOSから見た仮想HDD自体は
単一ファイル。仮想HDD内部アクセスは単一ファイル内部のランダムR/Wに還元
できる。いずれにせよ仮想OS配下のゲストOSが指定するLBAをリアルLBAに
変換してR/Wしているはずで、ゲストOSが発するtrimもそんなLBA変換が必要。
何年か前の記事にオラクルがVBでSSDサポートしたとか読んだことがある。
ま、そういうことでしょう。古いバージョンのゲストをWD-SMRで走らせたら？
人生時間のムダ遣いを避けるなら触らないが吉ですね。
>>79
あれは、三密ソーシャルディスタンスにかこつけたウィトディスタンスと
稠密密度書き込みという表現を使いたかっただけのなんちゃって薄口翻訳超訳なんで
シャレ、ネタの類。すまんね軽くてw 元表現は↓
“Even the people using Seagate SMR drives are reporting 10 second
pauses in writes at times and those who had reasonable performance
with SMR-from-start arrays have confirmed that resilvering a replacement
drive in has turned out to be a major issue which they didn’t fully appreciate
until they actually tried it.” >>81
どれくらい前のスレか忘れたけど、Mac OS Xを使ってる人がSMRドライブでファイルコピーしていたらなかなか完了しないで
転送が停滞して困るとかあったので、Trim対応とかちゃんとやってないんじゃないか？と思ったりした。
仮想系は数GBのAndroidのしか使ったこと無いけど、テラバイト単位の大きさだと1ファイルだとしても動作に影響しそうな気がする。
1ファイルでも多数のバンドに掛かっていると煩雑な処理になるかなとかで。
まあでも、自分のPCでWDのSMRディスクはWin10でソリッドステートドライブ扱いになって、最適化はトリムになるっていうのは、
正しかったんだな。どっちかというとハードディスク扱いになっているのはちゃんとサポートされてないって事で。 トリマブルディスク
相手は死ぬ
じゃなくてデフラグ不要・要トリム WDのSMRドライブはRAIDに向かないらしいです。SeagateのSMRドライブはなんとも言ってませんが。
と言うわけで、安物のYottamaster (4Bay) HDDケースRAID機能付きを買ったので、
ST6000DM003(SMR) + WD60EZAZ(SMR) + WD60EZRZ(CMR) + WD60EZRZ(CMR)
メインで使ってないSMRドライブとちょっと古くなったので放置されていたCMRドライブの組合せで
RAID0を組んで、貯まった録画ファイル15TBの予備を取っておこうと思いました。
コピー元ディスク1
TotalRead = 8,467,589 MiB
TotalWrite = 8,467,589 MiB
TotalFiles = 3,664 (265)
TotalTime = 14:45:13
TransRate = 159.4 MiB/s
FileRate = 0.07 files/s
コピー元ディスク２
TotalRead = 7,335,378 MiB
TotalWrite = 7,335,378 MiB
TotalFiles = 4,115 (326)
TotalSkip = 2,021,385 MiB
SkipFiles = 985 (0)
TotalTime = 11:02:51
TransRate = 184.4 MiB/s
FileRate = 0.10 files/s
Result : (ErrFiles : 0 / ErrDirs : 0)
２５時間ほどかかりましたが特にコピー中は応答不能とかなく、けっこう高速な転送速度を保ちながらコピーを終えました。
今は、SMRドライブたちはオフラインSMR処理をしているようでずっと動作音が続いてます。
１時間経っても静かにならないのがSMRドライブだなあとまったりしておりますw >>86
15TBでRAID0とは思い切った事をすると思うが
そういやRAID0だとHDDの破損検知をしないからSMRでも問題無さそうだな >>87
バックアップ対象のファイルを全部コピーできましたがチェックディスクしてみても特に破損ファイルはなくて良かったです。
正直、RAIDコントローラーのHDD障害判定に疑問を持つ方なのでSMRをRAIDに使っても実際の障害発生率はあまり変わらない
んじゃないかな？と思っています。
SMARTエラーが出て、HDDが故障した事（読めないファイルが出たり、破損ファイル多発など）の経験が無いし。 >>88
RAIDコントローラのHDD障害判定なんてアクセスした時の応答が規定時間以上の場合とかでしょ
それだったらHDDの電源が壊れた時とかにも対応出来て万能だからな
で、SMRだと正常動作でも時間がかかる場合があるので
RAIDコントローラに異常HDDと誤判定される事があるというのがよく言われてる話 一般論で言うとRAID対応HDDのTLER(ERC)は7秒に設定されてる
RAIDコントローラーは8秒間無応答だったり処理が完了しないと、そのディスクに異常が発生しているとみなしてディスクアレイから切り離す
これはストライピンク(RAID0)でも同じ
勿論、任意で時間を設定できる製品やNASもある >>90
本当にストライピングでも無応答で切り離しをするのか？
切り離しても誰も得をしないと思うけど >>91
理論値で言えば1時間とかかな
まあ、現実的に設定で回避が無理だから
SMR は使用禁止なRAIDコントローラーとか出てきてるわけだろうね 最近の5ちゃんねるって本気でウソ言ってたり、老化なのかテキトーなこと言って放置する人とか多くて、昔ほどアテにならなくなってるよね。 >>94
昔から嘘は嘘であると見抜ける人出ないと使えないと言ってるだろう
嘘の量なんて問題では無い
嘘を見抜けないと使えないのは変わらない どっちかというと5チャンの情報は嘘である可能性を
考慮した上で扱えば問題無いとは思うけど 人が居なくなったからね
昔などんなマニアックな事や人でもそれに関するスレがあったし。
数える程度の人で回ってれば知識量も限られる >>94
確かに根拠もなくデマ断定する奴とか増えたな >>93
ちなみにSMRドライブでRAIDするときに理論値とは言え、1時間とかどうやってその数字が出てきたの？
自分の持っているSMRドライブで30分でも応答不能から復帰とか無いんだけど。 >>100
普通はそんなに止まる事は無い
瓦書きってのから理解しないといけないが
SMRの瓦部分は小さいデータを書き込むのが苦手で
例えば4KBを書き込むのにも100MB分位書き込み処理が必要になる
それを回避する為にSMRではメディアキャッシュ（MC）という瓦では無い領域を20GB位用意していて
4KB等の小さい書き込みはMCに書いた時点でOSには完了を返して
後でこっそり瓦領域に100MB位の書き込み処理をして書き込んでいる
つまり小さい書き込みもMCの20GB内で収まってればあまり問題は無い
ただ、この小さい書き込みがMCのサイズを越えるとMCが空くまでSMRから書き込み完了が返ってこなくなって処理が止まる
例えば1MBの書き込みを一気に2万個実行してMCを埋めた後に20MBをSMRに書き込もうとすると
20MB分MCを空けなくてはいけないので100MB*（20MB/1MB）で
2GBの瓦書き処理が必要となる
100MB/sなら20秒だけど瓦書き処理は全部がシーケンシャルではないから数分はかかりそう
それに加えてこの間に他のプロセスからSMRにリードライトの依頼があったらいくらでも待ちは長くなる
ただ、20MB書きこむのに2GB分の瓦書きの処理が必要になるから
MCの空きが無くなると全体的に相当処理は遅くなるだろうね >>101
御説、もっともですが実際のSMRドライブでそのような現象が出ましたか？
持論を仮想SMRドライブを元に唱えるのは、ご自分の範囲では構わないのですがSMRドライブは市販されているのです。
自分が実際に使っていて、そのような現象に全く出会わないので、SMRドライブをご購入なさって再現性の高い条件を
示していただければ幸いです。 >>102
俺はこんな現象見たこと無いよ
御説が理解出来たならわかると思うがこんな事はまず起こらない
だから理論値だと言ってる
前にどっかのアマゾンレビューで買ってきて最初の
大量の画像コピーが進まなくて詰んだってのは見たことあるけど
あとWDのREDをこっそりSMR化したら
RAIDで動かない報告が多発して問題になってたから
RAID構築時にはMC溢れは起きやすいんじゃないかね >>102
最近各社SMRを明記する様になったでしょ？
あれって、米国でNASにWD赤(SMR)を使っててエラーが発生したかららしい
RAIDアレイの再構築は通常運用ではあり得ない書き換え付加が発生するからね 企業のRAIDで障害発生したら、家庭用とは違って高額賠償の可能性があるからな
問題解決できない以上、明記して使わないでもらうほかない、という流れ >>103
SMRのREDの件ってCMRで組んでたRAIDにSMR突っ込んで再構築失敗したとかじゃなかったですかね？
全部SMRならRAID0,1ならいけんじゃね？って事で、SMRで組んでるって書き込みどっかで見ました。
QNAPのnas公式でも互換性リストに全部同じ構成で組めとか書いて有ったりしますが、netgearとsynologyは
まだ否定的だった気がします。ただ、synologyの2.5"HDDはSMRが互換性リストに載ってたりします。
YoutubeでXignas(Linux)で検証した人がいて、結構行けんじゃね？的なレビュもありました。
思うに新技術なんで各メーカーが互換性リストに掲載するには検証不足で、載せるのはリスクが高いと
判断しているのではないかと思います。金銭的に余裕があるなら避ければいいかと。
それにしてもみんなRED好きだね・・・RAIDのRはREDのRだ！！なの？ >>106
何故CMRで組んでたRAIDにSMR突っ込んだら再構築失敗するのかって話
その要因がMC溢れで無いのであれば他にもSMRには難点があるって事になるけどな
まあ、MCからの瓦書きとSMR外からの書き込み処理が被って遅くなる事はあるみたいだけど
そっちの方の問題なのかね
それ位待ってくれても良いと思うけど >>106
REDが好きというか何の連絡も無く新型がグレードダウンしてたら話題にもなる
というか苦情も出るだろうと
むしろ何でWDは隠し通せると思ってたのか
もしかしてRAIDが組めない事がある事を把握してなかったのかな 規制食らった
>>107
メディアキャッシュ分小さい容量のHDD突っ込んだんでしょ？普通は再構築出来ないかと。
書き込みロジックについてはHDDのキャッシュメモリやメディアキャッシュで輻輳が発生してタイムアウトしている可能性はあるけど、それはOS側のフロー制御のロジックなんでファームアップで対応できるんじゃないかと。
同じシリーズで同じ容量で構成されてれば、おっそいかもしれないけどRAIDも再構築もイケるんじゃないかと思う。 >>109
なるほど、微妙なサイズ差か
だとすると新規構築だったらいけそうな気はするけどどうなんだろうな
ファームアップ対応は >>101 にある通り
SMRの待ち時間がほぼ不定な仕様だから難しいんじゃないかな 難しいし、何よりRAIDシステム売る会社が対応したくないんだから無理よ
対応しました、っていった瞬間責任かぶることになるんだから ま、RAID箱作っているような会社の大半は三流処だからね NAS作ってる会社がSMR-HDDに対応するメリットって基本ないしな
良く分からん挙動をする物なんて、非対応と言った方が良いからね >>106
分かっていてCMRのアレイにSMRのHDD入れたのならRAIDの修復を行った人の
問題だけど、あの件は元々入っていたのと同じ型番のHDDを頼んだら、後から
修復用に入手したHDDがSMRだったので問題になったって話だよ
SSDでもどっかがやらかして炎上したけど、経費削減のために中身を廉価な
H/Wに変えるっていうのはよくあるけど、CMRをSMRはさすがに特性が違いすぎて
訴えられたらやばいレベルだったんだろうねぇ
しかも型番分けますっていった結果SMRを新しい型番にして安くするんじゃなくて、
CMRに新型番を付けて値上げしているんじゃだまされたーってなるのも普通かな 猛者がいた
【高機能】 Synology 総合 part21
ttps://mevius.5ch.net/test/read.cgi/hard/1593901988/380 >>116
ガラクータSMR 9本 でRAID5とかw
1台死んだら再構築の負荷に耐えられなくて2台目が死ぬパターンだな >>95
嘘つき本人がこれ書いてるかと思うとゾクゾクする >>117
単に遅いだけだから、構築の負荷なんてそれなりでしかないよ
融通の効かないコントローラーなら不良ドライブとしてRAIDメンバーから外すかもね
そこは実装しだい >>120
融通というか実際Raidで問題が出たからWDRedがSMRであるのがバレたって話だからなぁ >>120
一度メディアキャッシュ(MC)を使いきったら、その後は超低速を維持するんだよ
その間ヘッドはMCからデータ待避で通常運用事だとあり得ない連続負荷
同時期の購入のHDDでRAID組んで、その内の1台が逝ったアレイの再構築だと、寿命末期に酷使されたドライブが次々と死ぬことに ■ このスレッドは過去ログ倉庫に格納されています
