【瓦記録】SMRのHDD 9台目【ﾌﾟﾗｯﾀ枚数減】
■ このスレッドは過去ログ倉庫に格納されています
!extend:checked:vvvvv:1000:512
プラッタ枚数を減らし、価格が安くなるかわりにがランダム書き込みが致命的に遅くなる技術
Shingled Magnetic Recording (SMR)を採用した、通称瓦記録のHDDについて語りましょう
次スレ作成は >>950
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は本当に遅いのか試してみた
https://ameblo.jp/iso5210/entry-12426001030.html
前スレ
【瓦記録】SMRのHDD 8台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1567896896/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >>239
どうせラストマンスタンディングなアホでしょ？
煽りしかできないタイプのさ >>240
NG入れて無視でもいいんだよ？
おれは耐性低いから反応するけどさ
君も反応する？ >>242
そう煽りしかできないタイプなのよ
いつまで遊ぶ？ >>251
だってこのまま行くと1000まで行くよ？ >>254
君がやめない限りやめないからさ
1000まで行くよ >>257
そう頭おかしのよ
だからお前に粘着するよ お前にできるのは無視するか、ココに書かないの2択
お前が反応する限り不毛なレスは続く さて、SMRで応答が遅くてもRAID成立する条件は書いたので、あとは皆さん適当に使ってください
つまり、俺環じゃなくなります BSは雨に弱過ぎ
なるほどネット配信こそ正義だわ
隆盛するのもうなずける 雨くらいでBSが映らないなんてないよ
CSの間違いだろ
CSは雲が厚いくらいでノイズが入るからな 内容はこれ >>217
●誰かの主張
SMRはRAIDに向かない、現にアメリカでNASで問題が出たじゃないか
●に対する俺環、反例
WDのSMRは知らないが、mdadmなら茂SMRでもなんとか維持可能 >>268
なるほど。既存データ記録済みのセクタ上書きが遠因しているかもね。
上書き更新について、海門-SMRはCMRライクでとりわけ特殊な処理は無用。
WD-SMRは上書き更新を行う際TRIMコマンドで上書きすべきバンドを予め
オールクリアしておくことが推奨されている。WDの上書き更新の機序は
まず別セクタ・バンドに上書き更新分を退避書きする。その後の空き時間に
本来的保存場所に書き戻すガベッジコレクションを行う。この一見無駄な
動作を省略するために、上書き前に予めTRIMコマンドで当該セクタをクリア
しておけば退避書き無しで一気書きできる。WDのSMRはそういう手順が
推奨されるホストマネージド。WD的TRIMの意義はSSDのそれとは似ているが
だいぶ違うみたいね。またWD-SMRは翻訳テーブル変換方式なので海門-SMR
のようなメディアキャッシュは持っていない。らしい。
CMR命でTRIMなんてシラネーヨなRAID環境だとWDのSMRは辛いかもね。
海門でもバンド書きがあるからCMRほど軽くはない。がしかしメディキャッシュが
バンドバッファとしてCMR的機能を果たすからWDの退避書きよりは軽い。かもね。
WDの件。訴状を読むと原告はNAS/RAID対応を公言する赤に無断でSMR投入した
マーケティング・ミスを突いている。フィリップ・モリスが自社タバコに健康被害
可能性警告の注意書きを明記しなかったことで敗訴して100億単位の賠償金を払う
ハメに陥った例にならって、原告団を構成すべく弁護士事務所は原告団勧誘をWEBで
やってるみたいね。日本からでも酸化できそうだが証人喚問とかで渡米要請されたら？
君子危うきに近寄らずですなあ。 被害者ビジネスの該当機種と募集要項は↓。
=======
The affected HDD (hard disk drive) models are:
3.5″ WD Red 2TB, 3TB, 4TB, 6TB
(SKUs: WD20EFAX, WD30EFAX, WD40EFAX, WD60EFAX)
3.5″ WD Blue 2TB, 6TB
(SKUs: WD20EZAZ, WD60EZAZ)
2.5″ WD Blue 1TB, 2TB
(SKUs: WD10SPZX, WD20SPZX)
2.5″ WD Black 1TB
(SKU: WD10SPSX)
If you bought one of these Western Digital hard drives and believe you have been a victim of this fraud, please contact us about your experience
========
Western Digital Lawsuit For Shipping Slower SMR Hard Drives Including WD Red NAS
https://www.hattislaw.com/cases/investigations/western-digital-lawsuit-for-shipping-slower-smr-hard-drives-including-wd-red-nas/ >>270
SMRなディスク単体と同じことで、追記中心の利用なら大して問題ないのよ
その追記もRAID5なら「(台数-1)*MC size」までは一度にできるし、MC回復時間は一台の場合と同じ
MC...メディアキャッシュ >>274
自作板にもかかわらず
情報提供皆無の煽りしかないやつが
本性晒してて笑うw
S Stupid
M Moron
R ​Ridiculous
自作板にいて作もなし
サイコ過ぎて粘着しかできないと来た >>276
一連のやり取りで、
無視って書いてるのはお前だけw
記憶力もおかしくなってるじゃんw 気にしないで無視すればいいのに
いちいち反応するのね >>273
実話はそのようなレベルの単純なお話じゃ無いみたいよ。↓URLの図表参照。
CMRな40EFRXなら878分で終わるresilver(再同期処理)が
SMRな40EFAXだと13784分。約16倍の9日半も掛かるのどうするの？
というお話。resilverって実装環境毎で実現手法に差異はあるだろうけど
ほぼほぼシーケンシャルな追記書き込みなのでは？ ってね。
ちなみに、俺的経験でST4000DM0004でMCがオーバーフローすると書き込み
速度は120MB/s程度から100KB/s以下と超低速化した。正常時対比で
書き込み処理時間は100倍以上遅くなった。いったんオーバーフロー状態にハマると
アイドル状態に戻すためにpはけっこうな時間がかかる。追加的書き込みを止めて
無作為で完全放置をキープしたままでは、5分経過程度ではMC内容のフラッシュは
終わらない。100%ビジーのかま。実測実体験的に15分間程度放置しないと
アイドル状態には戻らなかったですね。
いずれにせよ、resilver処理でSMR-HDDが問題を起こすとすれば、NAS/RAID
機器環境がたまたまタコだったから。だと思うね。WD曰く、プライマリなベンダの
機器環境でSMRなWD赤は問題はなく使える。と主張しているようだし。
https://arstechnica.com/gadgets/2020/05/western-digital-gets-sued-for-sneaking-smr-disks-into-its-nas-channel/ かま > まま
ああ、オッサンたちはまた始めるのか。マウンティング合戦w マウンティングなんて大層なもんじゃないよ
おちょくって少しでも精神的にイライラさせたいだけ
いちいち反応しないと気がすまない馬鹿だからやりやすい 折角のﾜｯﾁｮｲスレなんだから黙ってNGすればおk >>281
zfs絡みで目にしたことあるけど、resilverが該当記事には出てこない
でもって、件のNASはzfsだったみたいね
個々のファイルでCRC取るからかも知れん
それでキャッシュの効きが悪くなるとか
resilverの訳語は普通に再同期、またはingつけて再同期化だよね【念押し】
鋭い対比とかsneakingとか、いちいちもっともな記事だわ
記事紹介ありがとう
ここから本題
繰り返しになるけどbitmap onで追記箇所のみが同期する
「(台数-1)*MC size」内の追記ならCMRと同じ処理時間
例外はディスクの脱落からの再同期【重要】
新しく追加した一台に集中した書き込みがバックグラウンドで行われるので、応答が悪くなる
MC溢れでレスポンス鈍すぎるなら、その1台はCMRに付け替えとなるだろう んで結局のところSMRのメリットってなんなんだぁ？
まったくないわけじゃないだろうけど正直感じづらい >>289
比較的安い、それしか売ってない等々
実際は売り手のメリットだな ムリする・性能低下の代わりに安くて大容量で記録効率上がると言っても大体作る方のメリット
今までの方式の奴でいいからと言っても作る方の都合 作って売る方の都合でけったいな仕様製法採用、順次標準化で
表向きは大容量で安価になると見せて、質・性能面はこっそり劣化してるとなるというのはよくある
従来品がいつの間にか高性能な高級品化してみたり
CMRのHDD、3D-TLCのSSDがいつまで普通に買える物として残るものか… >>293
まさかQLCが実用化されてTLCを選んで買う事になるとはね
寒PROがTLC化だってさw SLCはほぼ絶滅したな。MLCも絶滅寸前。TLCも絶滅するのかねぇ？ >>289
性能面ではメリットなんて無いよ
存在目的はプラッタ内に多くのデータを詰め込んで容量を増やすことだからな
書き込みヘッドのスペック以上に詰め込んで書くから
書きこむのにえらい時間がかかる
それを誤魔化す為にメディアキャッシュ（MC）という不揮発領域にキャッシュを用意したけど
MCから本体への書き込むのが二度手間になるし
MCが足りなくなったら終わるしなのでCMRと比較して良い所は何もない 熱アシスト実用化されてもコンシューマー向け底辺(要は青)には降りてこなさそう
どうせ金とか赤pro(糞高い)で、青はSMRだろう >>289
CMR比でプラッタあたり最大50%の容量増 熱アシストの時代になるとsmrが必要なくなるだろ
1プラッタで10TBとかのレベルになってくると >>300
熱アシストはコストアップするんだよ
対してSMRは上位機種の再生ヘッドを使い回すだけでプラッタ減らせてコストダウンになるから 従来の磁気記録方法を用いたHDメディアの記録密度約1.14Tb/平方インチに対し、
HAMRでは将来的に5〜6Tb/平方インチを実現できるとされ、同じディスク枚数で
あれば3.5インチHDDあたり70〜80TB程度の記録容量が実現可能であると想定
されている。すでにSeagateがHAMR技術採用の16TB HDDを市場に投入している。
https://pc.watch.impress.co.jp/docs/news/1233963.html 補助金不交付決定
天皇弄りはあかんよな
あと、慰安婦像のパチもんみたいな奴とか 持ってもいない使ってもいないパーツの知ったかなんかは、糞アフィのITハンドブックにやらせとけばいいんだよ
あれは価格でも工作めいたことやってるそうじゃん
>>301
基本ファームウェア改修だけで済むからなー
まあディスク脱落からの復帰や容量の拡縮は負荷が大きいからSMRでは無しだ
CMR追加or別途新規RAID組んでファイルコビーとかになるのだろう
可用性はあるわけだからいいか
>>305
結局、金髪豚野郎の売名で終わったね、ってスレ違い HDDそろそろ6年くらい回してるからバックアップしとこうと思ってシーゲートの8TBSMRにコピーしようとしたら
600GBくらいまでは順調だったのにそこから残り2400GB部分で10MB/sまでレートが落ちて24時間くらいかかる見込みになった
バックアップにも向かないとかこれ1回だけ逐次書き込みしか使えないんじゃ… >>307
貴重なメディアキャッシュ溢れ体験おめでとうございます！w
それ起こそうと思ってもなかなか起こせるものじゃないみたいよ ああ、Fastcopy試してみてほしいね
俺はFastcopyでも回避出来ないと思ってるけど バックアップ目的でお立ち台系のクローンに使う分には別になんともないんだけどな >>312
LBAを頭から尻まで、シーケンシャルにコピーしてれば遅くならないかもだ
あとは実証あるのみ シゲSMRに貯め込んだデータの整理を行ってるが、
空き容量数十GBまで書き込んだ状態のドライブ。
GB単位のデータを数個〜数百個の単位で複数のドライブ相互で書き込みと消去。
USB接続なのでたいした速度は出ないが、
Fastcopyのベリファイ付きで完了時の転送レート表示は40〜50MB/secくらい。
HOSTのPCが組んで以来動きっぱなしなi5の3000代のWindows7機だけど。
こんな感じで気が付いたら20台以上使ってるが
極端な速度低下にはまだ遭遇してない。 mdadmの人です、
RAIDでCMR→SMRディスクに換装
備忘録：mdadm ディスク交換により再構成 2020/11/06
備忘録代わりに置いておく
TOSHIBA MD04ACA400 (FP1A) [CMR]
録画置き場として古めの2014年※製ディスクで2018年※※に組んだディスクアレイ、
6台のうち1台がSMARTで不良セクタ十数か所発生し交換、交換先は
WD WD40EZRZ-00GXCB0 (80.00A80) [たぶんSMR]
こちらは単品で使ってた2019年製
2020/11/06 23:15 開始
(-r)してmdadm止めて(-S)、電源落としてディスク外して付けて
パーティション切ってあるディスクを再投入、
パーティションテーブルはGPTなので、長いパーティション名が付けられる
なので用途と切った日が付けてある パーテションテーブルはこんな感じ
$ sudo gdisk /dev/sdm
Number Start (sector) End (sector) Size Code Name
1 2048 7814035119 3.6 TiB FD00 md46_4_14-12-28※
換装したディスクの追加
$ sudo mdadm /dev/md46 -a /dev/sdn1
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[>....................] recovery = 0.0% (343808/3906884352) finish=2083.0min speed=31255K/sec
bitmap: 15/30 pages [60KB], 65536KB chunk
md60 : active raid5 sdd1[3] sda1[0] sde1[4] sdb1[1] sdf1[6] sdc1[2]
29301946880 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 0/44 pages [0KB], 65536KB chunk
md60に比べmd46のチャンクサイズ、ちょっと小さかったかな……
ちなみに md60 は6TB x6、ST000DM003-2CY186 (0001) (全部SMR)
常用してるやつです 進捗その1
2020/11/06 23:36 10分経過、1%越えた
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[>....................] recovery = 1.0% (40728960/3906884352) finish=1849.5min speed=34837K/sec
bitmap: 14/30 pages [56KB], 65536KB chunk
ディスクアレイの状態
$ sudo mdadm -D /dev/md46
/dev/md46:
Version : 1.2
Creation Time : Sat Aug 25 04:05:32 2018※※
Raid Level : raid5
Array Size : 19534421760 (18629.48 GiB 20003.25 GB)
Used Dev Size : 3906884352 (3725.90 GiB 4000.65 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Fri Nov 6 23:44:25 2020
State : active, degraded, recovering
Active Devices : 5
Working Devices : 6
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 128K
Consistency Policy : bitmap
Rebuild Status : 1% complete
Name : ******:md46 (local to host ******)
UUID : 48a7e068:2be787f5:6250c029:5c11da89
Events : 57002
Number Major Minor RaidDevice State
0 8 161 0 active sync /dev/sdk1
1 8 145 1 active sync /dev/sdj1
2 8 129 2 active sync /dev/sdi1
7 8 209 3 spare rebuilding /dev/sdn1
4 8 193 4 active sync /dev/sdm1
6 8 177 5 active sync /dev/sdl1 進捗その2
2020/11/06 23:56 40分経過、2%越えた
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[>....................] recovery = 2.0% (80586112/3906884352) finish=1879.2min speed=33934K/sec
bitmap: 14/30 pages [56KB], 65536KB chunk
ほぼシーケンシャルだからSMRといえど、それほど時間はかからないはずだが……
まあ数字通りには終わんないのが常
以上！ >>320
mdadmの人ですって書いたのも読む余裕ないのかｗ
こんな時間に監視してるなら、役に立つ情報の一つも貼りゃいいのにな ところで、スレの24時間監視ってソレで食っていけるのかな？
賤業とは言わないが 2020/11/07 09:21
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[======>..............] recovery = 33.9% (1328283168/3906884352) finish=1099.2min speed=39096K/sec
bitmap: 7/30 pages [28KB], 65536KB chunk
なんか速度上がってるな
bitmapでスキップしたからか？ 2020/11/07 17:36
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[============>........] recovery = 64.1% (2505908792/3906884352) finish=606.5min speed=38496K/sec
bitmap: 1/30 pages [4KB], 65536KB chunk 2020/11/07 22:43
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[================>....] recovery = 82.1% (3208165076/3906884352) finish=347.7min speed=33490K/sec
bitmap: 2/30 pages [8KB], 65536KB chunk さて数字上のお時間なのでトイレついでにチェック
多分終わってないだろうなー 2020/11/08 03:50
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[===================>.] recovery = 97.1% (3796889856/3906884352) finish=68.0min speed=26910K/sec
bitmap: 2/30 pages [8KB], 65536KB chunk 終わる直前
2020/11/08 04:57
md46 : active raid5 sdn1[7] sdk1[0] sdl1[6] sdm1[4] sdi1[2] sdj1[1]
19534421760 blocks super 1.2 level 5, 128k chunk, algorithm 2 [6/5] [UUU_UU]
[===================>.] recovery = 99.9% (3906148976/3906884352) finish=0.4min speed=25738K/sec
bitmap: 2/30 pages [8KB], 65536KB chunk 総評
bitmapのおかげで実質はSMRに対し4.7TBの
シーケンシャル書き込みだったことに留意しとくべきである
複雑な上位レイヤ※は避けたほうがいいのか悪いのかは不明
$ df --si
Filesystem Size Used Avail Use% Mounted on
/dev/md46 20T 4.7T 15T 25% /media/***/md46_14-12-31
経過時間が30hだったとしてだいたい 156.6GB/h = 43.5MB/s か
糞遅ぇw そら訴えられるわ
金曜日の晩に始めてよかった
※btrfsやzfsなどは、CRCに重複排除と盛り沢山 mdの状態
$ sudo mdadm -D /dev/md46
/dev/md46:
Version : 1.2
Creation Time : Sat Aug 25 04:05:32 2018
Raid Level : raid5
Array Size : 19534421760 (18629.48 GiB 20003.25 GB)
Used Dev Size : 3906884352 (3725.90 GiB 4000.65 GB)
Raid Devices : 6
Total Devices : 6
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun Nov 8 04:58:52 2020
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
Consistency Policy : bitmap
Name : ******:md46 (local to host ******)
UUID : 48a7e068:2be787f5:6250c029:5c11da89
Events : 98565
Number Major Minor RaidDevice State
0 8 161 0 active sync /dev/sdk1
1 8 145 1 active sync /dev/sdj1
2 8 129 2 active sync /dev/sdi1
7 8 209 3 active sync /dev/sdn1
4 8 193 4 active sync /dev/sdm1
6 8 177 5 active sync /dev/sdl1 >>336
訂正
頭寝てたわこりゃ
SMRへの書き込み量は 4.7TB/5
書き込み速度は 0.94TB/30h
（計算時間を考慮していない値）
それ以降も悲惨な数値
= 31GB/h = 8.7MB/s ■ このスレッドは過去ログ倉庫に格納されています
