【瓦記録】SMRのHDD 3台目【ﾌﾟﾗｯﾀ枚数減】

**Socket774** (ﾜｯﾁｮｲ 23ec-QXT6) · 2018/11/01(木) 20:55:36.15

!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を語るスレ 2台目【ﾌﾟﾗｯﾀ減】
https://egg.5ch.net/test/read.cgi/jisaku/1533010435/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

**Socket774** (ﾜｯﾁｮｲ 0db1-HTYP) · 2018/12/30(日) 15:18:26.21

raidがなにか特殊なことをやっているかというと別になく、通電時間と台数とアクセスが多い可能性が高いだけだから
単に耐久性がないということ

**Socket774** (ﾜｯﾁｮｲ 76c5-GIAe) · 2018/12/30(日) 15:40:43.11

>>941
> RAID前提

んなけないやろ半可通が

**Socket774** (ﾌﾞｰｲﾓ MMde-jTn5) · 2018/12/30(日) 16:01:39.56

ゲーミングPCじゃないとゲーム出来ない理論

**Socket774** (ﾜｯﾁｮｲ 05e0-XvnK) · 2018/12/30(日) 16:03:30.31

RAIDが何の頭文字かググってごらん

**Socket774** (ｱｳｱｳｶｰ Sa4d-nbjb) · 2018/12/30(日) 16:07:13.36

安くなかったらRADに、、、

**Socket774** (ﾌﾞｰｲﾓ MMfa-PuKn) · 2018/12/30(日) 16:37:13.11

ま、まだIndependentと主張する余地はあるから（汗

**Socket774** (ｵｲｺﾗﾐﾈｵ MMad-0Zqm) · 2018/12/30(日) 16:42:08.78

>>952
RAIDは複数のHDDがアレイ単位で同時に動くので、振動センサーついてる方が良い。

SMRのように、書き込み単位が大きくなる事でのオーバーヘッドは無い方が良い。アレイ内HDDのメディアキャッシュ使用でHDD間にズレが生じたら残念パフォーマンスになっていく思う。(RAID0/5)

**Socket774** (ﾜｯﾁｮｲ 5502-z9X+) · 2018/12/30(日) 17:18:46.67

RAIDコントローラは、一定時間以内に反応しないドライブは「降格」させる。

むかで競争や長縄跳びでついて来れない子供を見つけた時点で、その子供に
失格の烙印を押して競技をやめる、すなわち、競技（RAID動作）自体をやめて
新たな選手の補充によるチーム再編成（リビルド）を要求するわけだ。

監督であるRAIDコントローラの指示に即応できないドライブは、RAIDで使うと
頻繁に降格したり不具合が起きてチーム全体の足を引っ張るので使えない。

HDDにはドライブ自身がエラー発生を自己修復する機能があって、その動作中は
RAIDコントローラからの命令に反応しない数秒間の無応答状態を生む事がある。

RAID環境下では、即応性の低い性能のドライブや、この自己修復が長くかかる時に
読み書きが発生すると、ドライブに不具合が発生していなくても問題が起こる。

そこでRAID向けに設計されたドライブは、エラー自己修復機能に時間制限を設けたり
RAIDコントローラからの命令が来てもちゃんと応じられるように作られてる。
WDならTLER、SeagateならERCと呼ぶ機能が関わってるから興味ある人は調べれ

**Socket774** (ﾜｯﾁｮｲ 91be-5EXd) · 2018/12/30(日) 20:11:19.48

速度低下ってそれを調べるためのベンチテストで故意に小さいサイズのファイルを大量に書き込んだときに起こるだけ？
通常使用でも起こり得るものなの？

**Socket774** (ｽﾌﾟﾌﾟ Sdfa-PuKn) · 2018/12/30(日) 20:30:18.38

>>960
その「通常使用」の定義を巡って宗教戦争が勃発するぞ

Seagateのデータシート基準で言うなら、1時間に約27GB以上のペースで書き込みされるとダメらしい
（年間55TB、稼働は8h/dの5d/w）
シーケンシャルもランダムもひっくるめての27GBだろうからランダムだらけだともっと脆弱と思うけど

**Socket774** (ﾜｯﾁｮｲ 7644-ulMf) · 2018/12/30(日) 20:50:39.20

>>949
基本的にはまったく同意見です。
レビューを書いた人が詳しく書いてないから、結局は想像でしかないですが、
amazonで買うくらいだから、おそらく家で個人的に使っていて、
大容量のストレージを複数のPCで共有したいだけなのかなと。
個人用途なら電源落とす設定も普通だと思っています。

注目しているのは、SMARTで3台警告、1台深刻な障害というところです。
デスクトップ向けが耐久性に劣るのはわかりますが、
2か月以内に7台中4台に不具合を生じるというのは、
NASとかRAID関係なく、配達のおっさんが手荒に扱ったのでは？
と思っています。
つーか、デスクトップ向けといわれるHDDでRAID組んでる人なんか大勢いますし、
それでそんなに壊れるなんて普通じゃないと思うのだけど。。。
家もHDDが2TB位の頃はデスクトップ向けでRAID組んでましたけど問題なかったですよ。

**Socket774** (ﾜｯﾁｮｲ 7644-ulMf) · 2018/12/30(日) 21:00:11.67

あー　長文だと論点がぼやけるな。

つまり、 >>934 の人は
NASに入れたから壊れたのか？
俺はそうは思わないって事です。

**Socket774** (ﾜｯﾁｮｲ 7576-5loh) · 2018/12/30(日) 21:33:07.19

NASのファームウェアがメディアキャッシュ領域からSMR領域へ移してる間のアクセスを考慮していなくて
省電力モードでディスクアクセス止めてしまって故障とかはありそうな気はするけどね
パリティRAIDにSMR向かないのも同様の理由だし

**Socket774** (ﾜｯﾁｮｲ 8912-Kqhe) · 2018/12/30(日) 22:41:55.73

SMRへの移動ってHDD内で完結してるんじゃないの？

**Socket774** (ﾜｯﾁｮｲ 7576-5loh) · 2018/12/30(日) 23:55:43.04

ACPIの管理はNAS本体（のファームウェア）の設定だから、考慮してないと
例えばHDDがまだ処理中にS3に移行してしまうようなケースが起きる

**Socket774** (ﾜｯﾁｮｲ 0db1-HTYP) · 2018/12/31(月) 01:46:51.02

ちゃんとS3に移行するなら別に問題ないんだが

**Socket774** (ﾜｯﾁｮｲ 76c5-GIAe) · 2018/12/31(月) 04:50:15.62

>>964
ディスクのファームウェアとその上層のディスクアレイ(NASが見るのはここ)、まずレイヤが違う
そして上層が安易に下層=低レベル側にちょっかい出すことはない
それは下層=ディスクのファームウェアが自分で判断する仕事

RAIDドライバ側からすれば、ドライバのログに「応答が無かったから〇〇ディスクは外す」と残す程度

実例
少なくともソフトウェアRAIDでは応答が遅いドライブはRAIDアレイから外すが、SMARTになにか残すだとかは無かったよ

2008年ごろのHGSTには、最大LBAをオーバーランして読み書きするとエラーを返さずに固まるというクソ仕様のディスクがあった
原因がわかるまでは何度もアレイ崩壊したｗが、SMARTには何も無しだった

**Socket774** (ﾜｯﾁｮｲ 76c5-GIAe) · 2018/12/31(月) 04:50:53.83

>>966
「今から電源落とします」は上層にあるドライバがディスクのファーム側に知らせる
ファームは処理を中断して作業再開のための記録を残し、停止してよいとドライバに返す

この中断～返答の処理にSMRかどうかはあまり関係ない

書きかけの瓦領域をただ廃棄してしまえば、SMR独自の残すべき記録は今キャッシュはどこの瓦領域をキープしているかだけとなる
つまりCMRの場合に比べ毛が生えた程度、ごく簡素なものになる

実装の細部を隠すため階層分け、隠してあればディスク操作の手順は従来と同じ
そのための解がドライブマネージド

**Socket774** (ﾜｯﾁｮｲ 7576-5loh) · 2018/12/31(月) 08:01:24.96

>>969
上層にあるドライバ（NASファームウェアのカーネルに組み込まれたデバイスドライバ）が
SMRディスクがメディアキャッシュ領域からSMR領域へ移してる間の応答が遅くなっているのを
反応がなかったと判断してしまって、故障と判断してディスク切り離してから
S1やS3に移行してしまったケースが>>934のケースじゃないのっていうことですよ
通常はスリープ移行しないんだけど、民生品は強引にやってるのも多いので

**Socket774** (ﾜｯﾁｮｲ 557c-COus) · 2018/12/31(月) 09:14:46.30

>>970
それはあるかもね。メディアキャッシュからSMRな瓦状バンドエリアへのフラッシュは
マジで時間が掛かる。推定20GB、フラッシュ速度が最悪10MB/sとすれば完全終了に
30分かかる。ただ実際の挙動はキャッシュに空きが10%とかできればキャッシング再開
するから平常運転に戻りはするけど、空きが小さければすぐ埋まってしまみたいでもある。

**Socket774** (ﾜｯﾁｮｲ 89dc-4fyn) · 2019/01/01(火) 02:47:00.77

https://www.ark-pc.co.jp/i/13131138/
https://www.ark-pc.co.jp/i/13131148/　

**Socket774** (ﾜｯﾁｮｲ 91be-5EXd) · 2019/01/01(火) 10:40:36.46

フルスピードで10GB書いたら5GBの書き込みに制限してキャッシュが空くのを待って
開いたらまたフルスピードで書くような書き込みソフトがあればいいの？

**Socket774** (ﾜｯﾁｮｲ da20-wOmR) · 2019/01/01(火) 12:30:19.38

祖父の買えた?魚竿スレの方がはやそうだな

**Socket774** (ﾜｯﾁｮｲ f907-tvdn) · 2019/01/03(木) 11:55:02.28

>>973
20GB程度のメディアキャッシュを30分くらいで掃き出し終えるので、20GBごとに30分の休止すれば効率よいかも。

**Socket774** (ﾜｯﾁｮｲ 1320-8PYz) · 2019/01/03(木) 13:49:02.57

それで8TB埋めるのは気が遠くなるなw

**Socket774** (ﾜｯﾁｮｲ 9902-dGI5) · 2019/01/03(木) 13:56:48.50

効率とは

**Socket774** (ﾜｯﾁｮｲ 9198-AtI9) · 2019/01/03(木) 14:49:32.49

バックアップに変更加えないなら、無圧縮zipである程度纏めて保存して、小さいファイル作らんように工夫すれば良いよ。

**Socket774** (ﾜｯﾁｮｲ 51be-mHCk) · 2019/01/03(木) 14:56:12.24

週1くらいの定期バックアップ用途で、多くても5GB程度しか書かないって場合はSMRでも問題ないよね？

**Socket774** (ｽﾌﾟｯｯ Sd73-HRNa) · 2019/01/03(木) 15:07:16.70

>>979
数GIGAのまとまったファイルなら良いが、数GIGA分の細かいファイルなら向いてない

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 16:41:37.68

>>979
大きなファイルはシーケンシャル扱いでSMRな瓦状バンドエリアに直書きするので高速。
小さなファイル、windowsが断片化を強いてランダム状で書き込む断片だらけのファイルでは
体感的にSMRドライブの方がCMRドライブより速いはず。CMRだと全部を直書きするため
シーク＆ライトを繰り返すからヘッド移動時間が重たい処理。SMRだとほぼシーク動作無しで
あるいは少なめで高速なメディアキャッシュに書き込んで取り敢えず終了する。

問題はコピーとか書き込み終了がユーザに知らされても、実は本当は未完了だという点だね。
ユーザ的視点でHDDがアイドルして無動作のはずと思っていてもバックグラウンド処理として
メディアキャッシュ→瓦状バンドへフラッシュが継続することだね。トランザクションの一種。
電源落とす場合はそのフラッシュ時間を考慮すべきかな。まあ、最近の外付けは電源イレッパ
だから無問題だけど。

**Socket774** (ﾜﾝﾐﾝｸﾞｸ MMd3-UsBV) · 2019/01/03(木) 16:52:24.05

頻繁に書き込み→削除→書き込みして断片化したHDDの場合でも、大きなファイルサイズならシーケンシャルライトされて問題にならない？
シーケンシャルライトになるファイルサイズっていくつからなんでしょうか？

**Socket774** (ｱｳｱｳｸｰ MM45-XTgG) · 2019/01/03(木) 17:15:39.06

READ DMA EXT / WRITE DMA EXTコマンドの事？

**Socket774** (ﾜｯﾁｮｲ d976-C9fp) · 2019/01/03(木) 17:22:58.58

普通に考えれば、断片化進んでる状態であればあるほどメディアキャッシュ領域からSMR領域へ移す時間が増大するはずだから
SMRのほうが早くなるっていうことはまずありえないと思う
（SMR領域へ移す処理まで終わってないと書き込み処理は完了していない）
シーケンシャルライトになるファイルサイズはデータシート公開されてないから分からないとしか言えないと思う

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 17:40:45.97

>>982
ファイルが断片化している場合、またコピー先のHDDの空きエリアが断片化していて
落とし穴ボコボコ状態の場合は、それぞれ注意すべき点はあると思う。
ソースファイルが無断片でコピー先も断片が無い状態ならUSB外付同士でも150MB/s程度は出る。
コピー先がほぼ新品でもソースの断片が数十から3桁程度だと100-120MB/s程度。4-5桁だと
200-40MB/s程度。という程度が俺的なソース断片の体感検証。

コピー先のHDDの空きエリアの断片状態は検証ツールを知らないので判り難い。が、当該HDD上の
既存ファイルの断片率と断片一個あたりの概算サイズでおおおよそ目安はつくかも。空き断片の
サイズが大きければシーケンシャル埋めされるだろう。問題があるとすれば、長大ファイルを
シーケンシャルかきこでコピーしているつもりでも空きエリアが小断片なのでランダム書き扱いで
メディアキャッシュがズズズと消費される場合があるみたいな場合。以前5GB程度のファイルを130GB
コピーしていたら110GB経過でオーバーフロー症状の速度低下(500KB-1MB/s)を見たことがある。

SMRのシーケンシャルコピーはHDDの空きエリア次第。というか、windowsのNTFSがこの空きエリアの
扱いについて無頓着でテキトーに詰め込みする点がイケズだと思える。

**Socket774** (ﾜﾝﾐﾝｸﾞｸ MMd3-UsBV) · 2019/01/03(木) 17:41:02.16

メディアキャッシュを通さないシーケンシャルライトならCMRとたいして変わらなそうな気もするけどどうなんだろ？
シーケンシャルになるファイルサイズって結構重要だと思うけど確認する方法とかないのかな？

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 17:42:16.66

200-40MB/s程度 >> 20-40MB/s程度

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 17:52:50.21

>>984
フラッシュ完了までといえば、CMRの方が短時間でしょうね。
ただメディアキャッシュまでなら SMRの方がはやいはず。
エクスプローラのコピーインジケータが早めに消えるのはSMRでしょ。たぶん。
ただし、パフォーマンスモニタではインジケータ消失後でも依然としてHDD使用率100%が続いたりする。

**Socket774** (ﾜｯﾁｮｲ d976-C9fp) · 2019/01/03(木) 18:26:22.00

>>988
エクスプローラのコピーインジケータの消える速さだけを見て目安にするなら
CMRのキャッシュメモリ内で収まる容量程度のものしか見ていないのと同じようなもので
参考にはならないかと

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 21:11:51.45

>>986
写真データ(小サイズな動画データを少し含む) 750本8.4GBを 4台のUSB3.0なHDDにコピーしてみた。
元データは SGの2.5インチ2GB 薄型。断片率 21% ST2000lM003

WD 2GB 断片率 0 2分7秒
WD 3GB 断片率 7% 2分33秒
SG 8TB 断片率 3% 2分5秒
SG 4TB 断片率 61%. 3分32秒
SG は ST8000AS0002 と ST4000DM0004 WDは緑。

ファイル占有率はすべて60-80%程度。条件均一じゃないので遅速の優劣は定かじゃないけれど
コピー速度には空きエリアの断片率、断片サイズが大きく影響していることは間違いない。

**Socket774** (ﾜｯﾁｮｲ 997c-KnXL) · 2019/01/03(木) 21:21:46.03

0004 >> 004

断片化がアクセス速度を阻害することは明らかだから、
HDDはワーク用と倉庫用と明確に切り分けて、編集作業はワーク用HDD上で
保存倉庫用はライトワンス&リードオンリーで使うのがベストみたいですね。

**Socket774** (ﾜｯﾁｮｲ 8bdc-RM76) · 2019/01/03(木) 22:37:03.94

次
【瓦記録】SMRのHDD 4台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1546521822/

**Socket774** (ｱｳｱｳｸｰ MM45-XTgG) · 2019/01/04(金) 01:59:04.35

dedefrag使えばよろしい

**Socket774** (ﾜｯﾁｮｲ 8bc5-6Wkp) · 2019/01/04(金) 09:29:45.91

e4defragつこうとる

**Socket774** (ﾜｯﾁｮｲ 51be-RM76) · 2019/01/04(金) 14:56:02.76

つこたのか

**Socket774** (ﾜｯﾁｮｲ 8b82-FGxz) · 2019/01/07(月) 21:26:33.17

**Socket774** (ﾜｯﾁｮｲ 8b82-FGxz) · 2019/01/07(月) 21:27:21.84

**Socket774** (ﾜｯﾁｮｲ 8b82-FGxz) · 2019/01/07(月) 21:27:50.32

ARA

**Socket774** (ｱｳｱｳｸｰ MM45-FGxz) · 2019/01/07(月) 21:29:43.99

smr

**Socket774** (ﾜｯﾁｮｲ b383-3A6Y) · 2019/01/07(月) 21:32:44.47

質問いいですか

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。

SLOT Results
🎰🎰🎰 Excellent!! 0
🎴🎴🎴 Gratz!! 0
🌸🌸🌸 OPPAI Ban!! 0
💣💣💣 Backingum!! 0
Win!! 1
Points 4 pts.

life time: 67日 0時間 37分 8秒

**1002** · Over 1000

5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php