2get ｽﾞｻｰ
WD赤にSMRが侵食中
Red WD20EFRX CMR(流通在庫のみ)
Red WD20EFAX SMR
Red WD60EFRX CMR(流通在庫のみ)
Red WD60EFAX SMR
Red WD80EFAX CMR？
Red WD100EFAX CMR(ヘリウム)
http://archive.is/TiLFR
SMR な HDD を使って Windows 8 からサポートになった記憶域スペースのパリティドライブを構築してみた備忘録です．
SMR な HDD の書き込みの遅さは色々なところで見るのですが，束ねてみたらどうなるのだろうということですね．
NEC Express5800/Y52Xa (Windows 10 Professionl, Xeon 1225)
Seagate ST8000AS0002 x 4台
Century CRSJ535EU3S6G2
エアリア SD-PESA3ES2L eSATA拡張ボード (asmedia 1061)
PC本体とは eSATA ボードを用いて SATA 接続されており，4台の HDD は SATA のポートマルチプライヤ機能を用いて認識されています．
で，まずは構築してしばらく使っての感想なんですが，
“遅い！！！”
です．約3テラのデータを書き込んでみましたが，平均して 12MB/s～13MB/s の速度しか出ません．
それも激しく書き込み速度が上下します．遅いときは1桁台の速度です．
もちろんこれは SMR 方式の HDD の特徴であることはあらかじめ分かっていたのですが，
今回は4台を束ねて分散して書き込まれるので少しは緩和されるかな…と期待したのですが4台位だと全く効果がありません．
単体で使っているのとほぼ変わらない使い心地です．結局，手持ちのデータの移動を終えるのに約1週間かかってしまいました．
;(；ﾞﾟ'ωﾟ');
👀
Rock54: Caution(BBR-MD5:1322b9cf791dd10729e510ca36a73322) >>4
初期のSMRですら100MB/s出てるから
明らかにポートマルチプライヤが原因だろ
eSATA接続というのも不安定要因だし >>5
茂の第一世代SMRであるアーカイブHDDですよ
数iopsしか出ないのを何台束ねても無駄な足掻きってのを実証したんだね >>6
俺の使ってるのもアーカイブ用だよ
ポートマルチプライヤーなんて
一つのSATAを分割するだけ
4台なら速度は1／4落ちる
一体何をしたいのかと ────以下、妄想と推測による「僕の考えたSMRの仕組み」関連書き込み禁止───
WD60EZAZ-RTはガチでTRIM対応してるんやな >>7
帯域が1/4になってもランダム4k
writeが上がる余地はあるだろ
貴方の理論だと、PCIeの16レーンスイッチでVGAを16x2 で繋ぐのと、8x2で繋ぐのが同じって言ってるんだぜ？ >>13
12MB/sじゃランダム4kにしては早すぎるでしょ >>16
SMRが出てくるまでなげえw
しかもテーブル管理方式ってなんだよ
専門家がググっても出ない言葉使ってるんじゃないよ
誰に向かって話してるんだよ LBAとメディアキャッシュの対応表をテーブル呼びしてるとか？
まあ、LBAも物理アドレスとの対応表あるはずだけどさ
メディアキャッシュだけじゃなくてSMR領域全てをSSDみたいに管理しているってことじゃね？
LBAとSMRの物理アドレス＋メディアキャッシュの物理アドレスとの対応表（テーブル）ということで
先週WDの赤6T買ったんだけどこれSMR疑惑あるんだよな?
何か見分ける方法ある?
>>21
適当なこと言うけど、CDIでtrimに対応していたらSMRとか？ >>23
11GBから速度が落ちたってのは興味深い結果だな
10GBしかMC積んでないって事かな？ 1TBしか無いならMC10GB程度しか積んでないのも当然か
同様のプラッタのCMRと実容量の差から出せたりしないかな
SMRはMC分実容量は少ないはずだけど
赤は
8Tと10TのEFAXはCMR
6Tと2TのEFAXはSMR
性能差があるんだからSMRなのかCMRなのか明記しろよな
どれが糞ゴミSMRなのか句別つかないじゃねーか
>>27
紛らわしいよな
同じAXなのに容量によってCMRとSMRが混在してるなんて >>21
>>9、ベンチマークやってランダムライトが異常に速ければSMR WD赤はもともと8T以上と6T以下で仕様違ってたし
WDは容量的にも安価ラインに8T出さなかったりと区別してる感はあるね
>>27
２Tでもあかんのか……orz
プラッタ容量できりがいいからなんでしょうか？
３Tならまだ安心していていいのかな… WD40EFRX-RT2はCMRだよね？
2TBプラッタ２枚仕様じゃないよね？？
WDスレから
個人的な認識としても以下と同じ
980 Socket774 (ｱｳｱｳｳｰ Sa5d-X02O)[sage] 2019/04/12(金) 07:49:10.72 ID:FmyArac+a
そろそろ次スレ頼みます
同じ型番でCMRとSMRを存在させるWDはクソ
Red WD20EFRX CMR(流通在庫のみ)
Red WD20EFAX SMR(2.0TB/プラッタ)
Red WD40EFRX-RT2 CMR(1.33TB/プラッタ)
Red WD60EFRX CMR(流通在庫のみ)
Red WD60EFAX SMR(2.0TB/プラッタ)
Red WD80EFAX CMR
Red WD100EFAX CMR(ヘリウム)
剥き身のドライブ買う時点で有る程度は自己責任で調べて機種選定ってのは思うけれど、
シリーズ型番同じで混ぜてくるのは擁護のしようが無いくらいダメだと思うわ
>>36
参考にさせてもらいます
紫も同じ感じなのだろうか…… >>36
これはひどい
海の向こうで訴訟でも起こされんかな Aが入ってるとSMRって認識してたんだけどそうでもないのね
HD-NRLD4.0U3-BAを買ったら、中身ST4000DM004で瓦だった
レコーダー行き決定。ライトワンスで使うか
単体ではともかく、RAIDで運用するとどうなるか不安
RAIDってそのコントローラーの仕様次第ではあるが無応答だとアレイから脱落する。
それはRAID0や1や5だろうが変わらない
瓦HDDでメディアキャッシュから溢れた状態になった場合、そのHDDは正常なのにアレイから脱落する可能性がある
RAID交換用に20000円も出せないから
普段はこれのミラーリングで十分・・・
>>47
どのディスクも同じ程度の負荷がかかるので、脱落するなら一斉脱落だな >>47
待ってくれれば良いだけなんだけど
たしかにCMRではあり得なかった待ち時間だから待てないかもな
ファームのアップデートで対応出来そうな気もするけど たったそんだけで？
と思ったがカカクならしょうがない
CMRでは起こり得ないなら興味深いけどそうでは無いんだろうな
メモリキャッシュが256MBになったのって、やっぱり
一時的にそこに転送して、あ、コレまとまってるから瓦に直書き出来るわって判断できるように
するためのもんじゃなかろうか
>>57
それも微妙であんまり不揮発領域に書くのを遅らせるとデータロストの温床になるから
そんなに揮発のキャッシュがあってもしょうがない気もする 単に旧世代64MBのDRAMだとコストがかかるから安い256MBのDRAMを載っけることにしたんじゃねえの知らんけど
メディアキャッシュ機構も引き継いでしまっている予感
パフォーマンス系の設定としてオン・オフが出来たらいいのに
ドライブマネージドのSMRでMCオフったらゴミになるだけだと思うが
ファイルの名前変えるだけでフリーズするぞw
>>61
違う違う、メディアキャッシュ兼『C』MRつーのが前世代の茂にはあったわけよ
おそらくはSMRバラクーダの露払いな
それと同様なら困るなってことよ そのうちSMRのHDDに大容量のフラッシュメモリをキャッシュとして搭載したようなのが出るんだろうか
瓦で出てるかまでは知らんけど不人気SSHDの事だろそれ
キャッシュを軽くみすぎなやつが多いなあ
DRAMの使い方にも影響しているし、サイズも大きくしている
MCを使うことでファームウェアのチューニングも変わってくるのに
ONだOFFだなんて気軽に扱えるわけがないだろう
>>63
だから揮発メモリだとデータロストするから駄目だって
それやったらSMRはパフォーマンスだけじゃなくて信頼性まで失う事になるぞ >>64
少なくともFirecuda 2.5はそれだな ごめ、フラッシュメモリは不揮発だな
それ単なるSSHDじゃないのか？
DRAMには物理/論理アドレス変換の為のLUT(ルックアップテーブル)と、リードキャッシュでしょ
書き込みは直接MC(メディアキャッシュ)へ
結局HDDのフルバックアップとかになったら書き込み遅くなるの？
大容量データが大半だったらどれくらい時間かかる？？
>>71
数十MB以上のシーケンシャルデータが大半を占めるのであれば
CMRと殆ど変わらないはず
MC経由しないで瓦に直書きされるので Ironwolfの12TBに新型がって話が有ったのでSMRを疑ってマニュアル見たら
従来モデルST12000VN007が
記録密度2283Kb/in、トラック密度392ktrack/inで705g
新モデルST12000VN008が
記録密度2426Kb/in、トラック密度436ktrack/inで690gで8プラ
とりあえずＣＭＲのままのようだ。
14TBモデルが追加されたようだしプラッタ記録容量アップは確実なんだろうけれど、
なんで軽くなったんだろ？
7プラ→8プラでプラッタが薄くなって軽くなったとか？
記録密度が増えたならプラッタ数は同じなんじゃないか？
マニュアルには旧モデルのプラッタ枚数が書いてなかったので、7枚の可能性もあるかなと。
新12TBは14TBと同じ8枚プラッタ。だけど15ヘッド。新10TBも8枚13ヘッド。
選別落ちなんだろうね。
旧モデルでも他モデルまで考えたら選別落ちは有ってもおかしくないかなと。
>>73
ああ、これ両方同じ容量なのか
じゃあプラッタが減って軽くなったんでしょ >>76
その程度はMCで余裕でなんとかなるって設計なんでしょ 9プラは東芝が2018年8月に世界初アピールしてたし、
2017年の旧モデルで9枚は無いと思う。
つまり旧モデルは8枚か7枚。
だからなんで軽くなったんだろう？という話。
15g程度なら剛性維持したまま薄くしたりで削れる範疇かと
なるほど。
ヘリウムもこなれてきて削りどころがわかるくらいの技術蓄積ができた可能性か。
プラッタ薄くなるとはいえケース方面でも9枚プラッタ以上を睨んで内容積増やす進化もするだろうし。
基板小さくなったとかも有るかも？
うん。わかってる。肉抜き的な感じにケースをシェイプアップするってことでしょ？
もともとヘリウムのケースは見た目的にも外側削るのは無理そうな感じだし、
内側を削る方向かなと。
ヘリウム用プラッタは枚数に応じて薄いものを採用しているから、
9枚プラッタには9枚用の薄いプラッタを使うんだけれど、
ケース側の削りで内部の厚み空間を少しでも確保できるのなら
それに越したことはないのかなと。
これ、Raidのリビルドとか無理じゃね？
時間かかりすぎて他が壊れそう
前スレでどこかのNASメーカーがSMRとしてリストアップしてたやつでしょ。
重量がアレだからまた誤記かね。
>>86
NASのメーカーは単純にSMRだからで制限はかけてない
挙動が合わないから他と混在させるなと言ってる
>>86
チャンクサイズを大きめに取れば、基本的に何やっても直書きになるよ >>90
「シーケンシャル」が抜けた
チャンクサイズを大きめに取れば、基本的に何やってもシーケンシャルは直書きになるよ ・キャッシュ256MB
・最高転送速度180MB/s
この二つが記載されていたらほぼ間違いなくSMR
>>95
そのHBAドライバに手を加えなくても動くのがドライブマネージドなんじゃないかと
そして動作した上でパフォーマンスを上げるのが最適化じゃね？
何にせよ日に日にSMRが増えていく昨今Droboはどうするつもりなんだろな
SMR使うな言われても見分けるがつかないっつーのなw つーかメディアキャッシュから瓦領域へ転送する段階でもしデータ化けが起きたらどうなるんやろ
>>96
If used the wrong way, I/O processing times of DM SMR HDD-based RAID arrays
can extend far beyond OS and application timeouts, causing hangs and even data loss,
much like an individual SMR device.
The use of DM/HA SMR drives in RAID is therefore only recommended in such environments
where the level of random write I/Os is low and controllable.
ちゃんと書いてあるから読もうね drobo使う意味ある？
NASとしてはあんまり…
複数の容量HDDを効率的に使うのが利点だけど今ならSHRとかあるし…
売ってる以上は使いたい人はいるんだろ
そもそもそれは本題じゃない
>>100
raidをなんだと思ってるんだw
コントローラーは毎年買い替えるものじゃないでしょ >>97
SMRを正しく見分ける方法をレスしたらHDDスレ界隈で一躍ヒーローになれるぞ キャッシュ128MB以上はまずSMRでいいんじゃね
7200回転の上の方のモデルは、CMRで128MBなんてざらにあるから
それは無理がある
>>98
データ化けが起きるようなら内部でベリファイしてるでしょ
逆にメーカーにそこに手を抜く必要性が無いと思うが >>108
買う前に判別したいのなら、メーカーに問い合わせるしかないですね SMR見分けたければトラック密度と磁気記録密度を調べるのが一番
非公開やスペック表記載ミスもあるが、SMRは明らかにトラック密度が高い。
>>95
ドライバの最適化とは書いてないような。
>>99
「RAID したって SMR は SMR なんだから使い方に気をつけろ」って書いてあるだけなような。 droboがSMR対応するかHDDメーカーがSMRを明記しない限りdroboはしぬ
というか未だにSMRに対応しないって事はdroboは店仕舞する気なんじゃ？
DroboがダメだからSMRに対応できないと思っちゃうのは短絡的かもな
実は「真面目なDrobo vs サボってる他メーカー」って構図だったりして
http://2chb.net/r/jisaku/1551107096/864
他メーカーでSMRで検証自体してなくて実際にはSMRが原因でトラブル起きても
SMRが原因と特定する技術力もがなくてSMR非対応とは明示していないだけなら
それは技術力があってSMR対応してる良いメーカーとは言えないよな(´･ω･`) >>117
ただ drobo はサボる事を明言しちゃったんだよな
対応予定とか何も書いてないから みなさん！いまのうちにSMRドライブに移行しておけば
将来的に交換が必要になってもSMR/非SMRを混在させずに済みますよ！！
ぜひぜひ！
SSDが安くなりまくっていらない子になるだろうなぁ
>>121
混在させてなくてもRAIDコントローラーは
落ちこぼれがいたら即クビを切るんだよね >>113
Drobo 2nd genシリーズではあっさりSMRに対応する可能性だってあるぞ
知らんけど >>118
まさにその通り
2TBﾌﾟｯﾀﾗ 5枚 10TBのWD青 15,000円で既存技術で作れるだろ
HGSTには空気で5枚なんて普通にあったんだから、出し惜しみしてんじゃねーぞ WDのCMR8TB～10TB、シーゲートの10TBや12TBのCMRのラインアップが消えるくらいにならないと
SMRドライブの枚数アップは無いだろうね。
アシスト記録のドライブが出てきて高付加価値のモデルが軒並み容量アップしてからだと思う。
そういえば将来的には現行の1.8TBプラッタをベースにしたSMRとか出てくるんかね？
シーゲートのマニュアルだとSMR2TBプラッタの記録密度は1.33TBプラッタ程度。
この倍率でいけると仮定すると1.8TBベースになればSMR2.7TBが可能となる計算なんだけど。
コレを6枚詰め込めば空気SMRで16TBドライブが作れることになる。
TDMRの前にSSDがSMR追い越して終了しそう
有線LANと無線LANみたいに
TDMRって十年以上前から実装されている海門の垂直磁気書き込み技術でしょ。
マニュアルpdfとかに記述あるはずだし。未来技術というより枯れた技術じゃないの？
そうか、ヘッドを複数個斜めに並べて配置すれば一気に書ける！
とか真面目に考えてたりするんだろうなw
でもリードはもしかしたらSSDを超える爆速になる希望はあるな
多分無理だろうけどw
プラッタぶん回す羽目になって 故障率跳ね上がるやろ
プラッタだけじゃなく逆方向にヘッダも回転させたらいいのでは…
天才かもｸﾞﾙｸﾞﾙ(´･ω･`)ｸﾞｰﾙｸﾞﾙ
書込みはSMRより遅く読み込みはSSDより速いって凄い使いにくそうだなw
メディアキャッシュがなんとかしてくれるか？
>>139
茂がやってるデュアルアクチュエーターに期待
>>134
16列並べて二次元記録すれば良いよね
斜めに並べて一気に瓦書きすれば良い 複数プラッタの同時読み書きもできないのにそんなことできるかな？
LTOとかは確かに並列読み書きだけど
同時書き込みは制約大きいね。
トラッキングやリトライの問題も有るし、
何よりそもそもトラック間隔は全域で固定間隔ではない。
ヘッドのスキュー角に応じてトラック間隔は中央部が狭く、内周外周に向かって広くなる。
2段アクチュエーターみたいな技術で連装ヘッドの間隔をそれぞれ調整しないといけない。
シゲのデュアルアクチュエーターはホストに制御コマンドの並列処理を要求している。
つまりドライブ内部で2つのアクチュエーターを自在に動かして自動的に高速化するのではなく
ホストが2つのドライブを制御するような状態。
ポン付けでメリットが得られる物じゃないよ。
>>143
なんだ、それなら2台積めば済む話じゃね？
MCから2次元記録ブロックにヘッド to ヘッドでデータ転送できる様になるのかと思ったが違うのか 本当に有用な技術ならWDも東芝も開発に乗り出してるだろうし、
MACH2は微妙だと思う。
>>146
ごめん二段アクチュエーターだね、間違えた 2段アクチュエーターは富士通が特許とってたね。
東芝にHDD関連事業が譲渡されたときにヘッド事業部は消えてるけど、
東芝も2段アクチュエーターを採用してるから特許関連は引き継いだのかね。
IBM系でも使ってたような記憶。富士通のヘッドを買ってたってことかしら。
IBM➡HGST➡WDの流れだっけか
MaxtorはSeagateからｻﾑｿﾝ?
2015年までだけど
>>133
その人の推測は多分間違ってる。
ＱＲコードはカメラで読み取るためにやってるのであって、HDD で二次元的に描いても意味ない。
バンド丸ごと巨大セクタのように扱うのも、ランダムリードが致命的に遅くなるのに対し
増やせる容量がほんの僅かで割に合わない。
コメント欄でも指摘されてるけど、二つのヘッドを使い読み取り精度を上げる技術。
SMR よりさらにトラック数を増やせるが、やることは SMR と大差なし。
でも、２倍とか可能になるなら意味合いは大きく違ってくると思う。
高が５割り増し程度じゃ使う気になれない自分も、倍となると流石にね……。 TDMRは記録に必要な磁性粒子の数を減らす技術でしょ？
だから必然的にトラック幅が大きく減る。
二次元化はエラー訂正の為のもの。
アレイヘッドはそのエラーを少しでも減らす為に少ない磁性粒子からより正確にトラックデータを読む為のもの。
>>152
> その人の推測は多分間違ってる。
SMRも最初のは間違ってたし、良いとこなしやん HGSTのDC530で「TDMRの技術を一部使用した」ってヤツもアレイヘッドじゃないかと思ってるんだが、
一部採用の中身って何か発表されてたっけ？
何にしてもTDMRは新技術盛りだくさんだから、
SMRを先行実用化したように徐々に実現していく感じなんだろうね。
少しづつでも実用化して開発費を回収していかないと厳しそうだし。
理解できていないくせに
知ったかぶりの妄想は
デマに等しい。
他でやってくれ。
最安価格(税込)：\13,198
ST8000DM004 [8TB SATA600 5400]
最安価格(税込)：\16,466
いくらSeagateと言えどもどうせ同じSMRなら\3000足すだけで2TB増える方選ぶわな
そしてさらに2000円足して東芝のCMR 8TBを買うと。
発熱と消費電力的に高速回転のHDD要らないんだよな。
5400回転クラスの選択だと、WD REDはオフラインスキャン無い、壊れやすい。BLUE（Green）も壊れやすい。
ってなると選択肢はseagateしかないんだよな…。
SMRだけど、割と信頼してる。
低回転モデルの選択肢増やして欲しいわ。
>>161
プラッタがギッチギチに詰まってる上に高速回転だからすぐ壊れそう
（あくまでイメージ） HDDってどこが主に壊れるんだろうな
プラッタやヘッドだったら単純にプラッタ多い奴の壊れる可能性が高くなりそうだが
そんな話は聞いたことが無いからコントローラか電源なんかね
信じられないかもしれないが先っちょの小っさいヘッドがポロリと取れる
HGST以外でありがち
そういえば最近のドライブは袋に乾燥剤入ってないね。
>>166
ついこないだ箱入りの今年の2月製のWD60EZRZ-RTを2つ買ったけど、フツーに帯電防止袋に乾燥剤と一緒に密封されてたよ。
代理店がやってんのかな？ >>163
確かに大容量HDDなんてデータのバックアップ用途に追いやられてるんだから、
（減らした分だけ信頼性が上がるとすれば）5400rpmで十分なんだよね >>167
帯電防止袋はWD工場出荷時に梱包してる(その外側のプチプチと青箱は代理店だが)
WDの場合はヘリウム入りドライブは省略してるっぽい
数年前のWD80EFZX(旧ヘリウム)には乾燥剤入ってなかった
最近買ったWD40EZRZ-RT2には乾燥剤入っていた
どちらもCFD青箱 復旧率95.2％を誇るデータ復旧のプロに「RAID障害に関する疑問」を根掘り葉掘り聞きまくってきた
https://gigazine.net/news/20190507-digital-data-recovery/
-----
井瀧： 修理のしにくさで言うと、RAID-Zとかですかね。
G： RAID-Zというのは……？
井瀧： ファイルシステム自体がZFSというものなんです。RAID 1とかRAID 2とかの数字がついている
ものは、正直結構簡単に直せます。ディスク単位でデータが分散されているものなので。ただし、RAID-ZやDroboのRAIDなどは……。
G：やはりそれぞれのメーカーが独自に作ったRAID規格はヤバイ、というようなイメージなのでしょうか。
井瀧：ああいったものは市販でも復旧ツールがないので、復旧会社などが独自に開発しているツールを使わないと直せないです。
RAIDは逝くと大変みたいだね～ >>171
RAID1って只のミラーリングじゃんw
RAID2ってまたほぼ普及してないマイナーな物をあげたな >>172
分かってないのか喋ってるときは詳細を忘れてたか 単純に復旧業者の顧客としては結構な数いるって事なのかもな
まあいずれにせよraid5,6も簡単に直せるとは言っているのでそんなに噛み付くような話でもないとは思うが
>>172-173
「Raid Z＋数字」と「Raidのあとに数字だけつくもの」を区別するために
「1とか2とかの・・・」と言っただけで
具体的にRaid1やRaid2を指しているわけではないと思う バックアップ取っとけば良いってよく言うけど
バックアップ取るとなると単純にHDD代倍かかるって事だよな？
HDDメーカーは低品質な製品を売っても
売り上げ倍増で儲かりますな...(´・ω・`)
>>178
HDD代倍の方が、データ復旧サービスより安い 大容量を複数台なら復旧サービスのほうが安そう
消えたら自殺もんのデータなら復旧あてにせずバックアップ取るけど
見られたら自殺もんのデータでも復旧あてにせずバックアップやで...(´・ω・`)
>>181
業者費用は比較的安いと言われる海門ラボでも数万/台。ボッタ系業者となると
GB単位の出来高払いで数十万/台と容量次第の青空天井。10万以下は稀。らしいね。
8TBなら今や2万以下なんだし。ups共々費用数万で鉄壁でしょ。 「2019年はPC用HDDの販売数が半減する」とHDD部品で世界シェア1位の日本電産が予測
https://gigazine.net/news/20190508-pc-hdd-shipments-predicted-drop/
日本電産が発表したデータによると、2010年に6億5000万台だったHDDユニット販売台数は、
2018年には3億7600万台にまで減少しており、下げ幅は実に43％。この減少傾向は今後も
持続するとみられており、当初は2019年のHDD出荷台数を3億5600万台と見込んでいたところ
を、2019年3月期の決算説明時には3億900万台に下方修正しています。2020年にはさらに
販売台数は減少し、2億9000万台にまで減少する予測だとのこと。
中でも大きく販売台数が減少しているのがPC用HDDであり、半導体メモリを使うSSDへの
移行および市場の弱まりが大きな要因となっているそうです。PC用HDDの販売台数は
2013年の2億8900万台から2018年には1億2400万台まで減少しているだけでなく、
2019年の予測販売台数は6500万台と、2018年から2019年の下げ幅は実に48％にもなると
みられています。ほかの分野においてもHDDの販売台数は減少傾向にありますが、
外付けHDDについてはほぼ横ばいとなっており、データセンター用途のHDDは上昇すると
予測されています。
----
数年先ともなるとデータセンター用途の二桁TBな大容量SMR/HDDしか生き残らないのだろうね。 ギガジンみてたら日本電産の予測では2019年でHDDの需要は半減だという記事があってたまげた
HDDの需要か。
一般ユーザーがますます買わなくなって販売台数は減、
エンプラ向け需要ばかりになって金額ベースの市場規模は変わらず
って感じじゃないか？
アシスト記録以降のドライブは容量単価変らずに、容量が増えた分だけドライブ単価が上がるイメージはある。
記事を読めばわかるけど2010年比で半減だからね。
別に驚くほどの話でもないんじゃないだろうか？
個別の起動用ドライブはSSDになり、データ用は大容量化で台数ベースだと減
クラウドも全データをHDDに入れているわけじゃないみたいだし……
常時動かしてるようなのは2.5インチHDDでいいのに
悪い(といわれてる事象の原因)はSMRにあるのではなくドライブマネージドにあるといってもいい状態だし、
いまのところ出てるデータセンター用SMRはホストマネージドだしで
問題ないんじゃね？
>>192
用途によるけど、Backblazeでは使えないと判断してCMRなMG07ACA14TAを選んでるな
SMRはコスト(メーカーが得をする)面しかメリット？がないのでは 倉庫として放置するなら（壊れてても気づかないから）大丈夫なんじゃないでしょうか？(´・ω・`)
リードライトの負荷も掛からないし。
数年後に取り出そうとして負荷かけたときに死んでも知らんが…
>>196
突然死のリスクはCMRもSMRも変わらんだろう
そこまで言うならLTO使うべきだ そもそも何をもって「大丈夫」としてるのか不明だし
設置や保管の環境によっても違う。
条件のすり合わせもない丸投げ質問なんだから
丸投げで答えるしかない
>>193
いや悪いと言われる原因は瓦書きでしょ
アレのせいで安定した書き換えが出来ないからCMRと比べて色々不都合が出るわけで
まあ例えば元々ギガバイト単位のデータしか扱わないようなサーバーであれば
ホストマネージドでSMRをバンド単位でしか操作しないように運用すれば
CMRと遜色無く使えたりするのかな >>195
SMRは激しい書き込みを行った際に稀に極端に処理が遅くなる事があるだけ
ちょっと位待たされても許容出来るのであれば問題無い
因みにraidなんかだとコントローラがそのちょっとの待ちが許容出来ないから使えなかったりすると言われてるね 人によって許容量が違うからね。ちょっと待たされる（数時間から数十時間）なんて平気な人がこのスレには多いんだよ。
テラバイトのHDDでRAIDを組むとリビルドに1週間とか普通でしょ？ね？って感じ。
>>201
不具合じゃなくて不都合な
その >>9 にも全体的にパフォーマンスが落ちるという結果が出てるでしょ
そのパフォーマンスが落ちる原因はMCを使用してるからで
そのMCにはさらにMC容量いっぱいになってしまったら空くまで書き込めなくなる制限がつく
で、なんでMCを用意する必要があったかは瓦書きがCMRと比較して遅すぎて使い物にならなかったからと
SMRの悪い所は全て瓦書きに集約される
だから当然ホストマネージドにしたからといってCMRと同じ様に使えるわけもない
そもそもホストでマネージドなんてしなくてはならない事自体も不都合であるし
ホストマネージドでも瓦書きで遅くなるのは変わらないので
ホスト側各々でうまく誤魔化して使ってくれと匙を投げられただけでもある 12TB以上一気書きすると不具合発生するのが瓦だよ
WD, SGそれぞれのSMR HDDの動作検証です。
ようやく環境が整ったので、数ヶ月振りに測定してみました。
----
OS
Win10 pro 64bit
データ元
XQD
121GB
6567コ(1ファイル19MB程度)
コピー方法
エクスプローラの標準コピー
所要時間を測定
Format直後のHDDへのデータ書き込み
WD60EZRZ(CMR)
14m45sec
WD60EZAZ(SMR)
11m27sec
ST60000DM003(SMR)
18m13sec
----
意外にも、WD60EZAZ(SMR)はWD60EZRZ(CMR)よりも早かったです。優秀です。
一方、ST60000DM003(SMR)は一番遅かった。
いずれも途中で極端に書き込み速度が落ちるようなことはなく、メディアキャッシュ
を経由してるのかしてないのかよくわかりません。
今回はFormat直後のまっさらなHDDへのデータ書き込みでしたけど、準備が出来れば
半分程度使った状態やほぼ使い切った状態での測定もやってみる予定。
>>206
いずれも同一の外付けHDDケース(USB3.0)に入れた状態での測定です。 >>208
0が1コ多かったですね。
ありがとうございます。 >>206
同一条件下でのFastcopyを使用した検証きぼんぬ
（自動的にログファイルが作られるので完了時間もそこに記録される） WD青6TBはCMRは1.2TBプラッタ、SMRは1.33TBプラッタ世代と思われるので
素のドライブ性能はSMR版の方が上になる。
直書きできてるのならSMR版の方が速くても予想通りではある
SMRってデータ保持性能は問題無いの？
倉庫として使うつもりなので、それだけが気がかり。
揮発だな、volatile memoryから来ててvolatileには不安定な～というニュアンスがある
evaporation memoryではない
しかし、不揮発メモリーとかなんか違和感あるよね、保持性メモリーとかにしておけば良いのに
>>213
技術的な面で問題あるかないか明記されてるのは見たこと無いが
問題あったら完全にSMRは終わりだろうから多分問題無いんじゃね この先パターンドやら磁気場やら熱やらあるんでしょ？
平気平気
2019年には海門から新技術を採用したHDDが一般に販売されるとのことだったけど
順調なんかな
>>191
9mm2.5インチHDDって24時間稼働対応してないから、そんな使い方をしたらすぐに逝くぞ
15mmの鯖用は大丈夫 3.5インチだと24時間非対応でも何の問題も無く常時稼動してる人が多いと思うけれど、
2.5インチは壊れやすいの？
物理的駆動があるものは小さい方が壊れやすいと思うが
以前は2.5は運搬前提で耐久性より耐震性を重視した設計で
3.5はその逆とか言われていたけど
もう有意な差はほとんど無くなっているのかな
余ってた2.5 HDDをテレビの録画に使っていたら1年以内に壊れたけど、なんで大丈夫って方向になってるの？
っていうか、2.5 HDDってSMR多いよねって話しないの？
2.5や3.5の差で壊れやすさを結論付けるほうがおかしいだろ。
熱処理、振動処理次第じゃないの？
ゴミケースで使うとどっちも壊せるよね。
2.5インチのアルミケースとかHDDがアルミに触れないケース多いし・・・
>>221
HDDの主要コンポーネントであるスピンドルモーターについて、例えばNAS用(24時間前提)WD赤とそうじゃないWD青で作り分けると思う？
答えは否、数まとめて一括仕入れした方が合理的だし価格も安く在庫管理上もメリットがある
つまりメーカーが保証しないだけで、基本的な中身は24時間対応できるだけの耐久性マージンがあると推測される
(もちろんRVSセンサー着けたりして差別化はするけど)
これは東芝MGとMDにも当てはまる
物が別物になる薔薇と鉄狼には当てはまらない
つまり3.5インチでも薔薇は24時間使うと壊れる
2.5インチは、そもそも24時間モデルが無いから、マージンなんて必要ない 707 ：Socket774 [sage] ：2005/12/02(金) 23:35:12 ID:pjeoc1vk
＜一目で分かるHDD故障確率＞
○HDDのMTBF（25℃時）
2.5インチHDD 30万時間程度
ATA/S-ATA HDD 40万～60万時間程度
SCSI HDD 100万時間程度
企業向け高寿命HDD 100万～140万時間程度
実際の使用温度が25℃超の場合、↑の値に対して以下の数値を掛ける
30℃：0.8 35℃：0.65 40℃：0.5 45℃：0.4 50℃：0.3 55℃：0.25 60℃：0.2
使用 MTBF（万時間）
期間 5 10 20 30 40 50 70 100
１年 16%. 8%. 4%. 3%. 2%. 2%. 1%. 1%
２年 30% 16%. 8%. 6%. 4%. 3%. 2%. 2%
３年 41% 23% 12%. 8%. 6%. 5%. 4%. 3%
４年 50% 30% 16% 11%. 8%. 7%. 5%. 3%
５年 58% 35% 20% 14% 10%. 8%. 6%. 4%
８年 75% 50% 30% 21% 16% 13% 10%. 7%
１０年 83% 58% 35% 25% 20% 16% 12%. 8%
2.5をP2Pのキャッシュに使ったら1ヶ月未満でご臨終に('A`)
>>228
組み上げてみてテストの成績が良いものを上位品として売るくらいはしてるんじゃね？ 令和世代はVelociRaptorなんて知らずに
SSDが当たり前で産まれてくるんだよなぁ…
>>231
WD赤ならやってる
しかも、3D Active Balance Plusなんてまるでセンサーでも内蔵しているかの様な(6TBまでは内蔵してない)大層な名前まで付けてね
良く良く説明見ると、只のディスクシフト選別と言う... >>232
VelociRaptorは確かに2.5インチではあるけど、基の設計が一時期流行ったブレードサーバー向けの24時間対応モデルだからノートに内蔵している様な物とは別物だよね(発熱も別物...)
3台使ってたけど全て3万時間越えてもピンピンしてた 24h対応の2.5はTravelstarにあるだろ
しまいに2.5のSASって知ってる？とか言いそう。スレ違いもいい加減にしろよ。
【速報】大量のファイル保存目的でSMRドライブを購入して罠にはめられた人が発見される（日本Seagateの返信あり）
https://www.あmazon.co.jp/gp/customer-reviews/R22Z6U2J8MDSCC/ref=cm_cr_othr_d_rvw_ttl?ie=UTF8&ASIN=B07911QK3X
Mizu
5つ星のうち1.0大量のファイルがあるとダメ
2019年5月12日
容量: G : 8TBスタイル名: PC向け 3.5インチ
SMRが普段使いできるレベルに改善されている、という記事を読んで買ったのですが……嘘ですね。
私の使い方では、全くダメです。古いデータを移動させる時点でつまずきます。
小さいファイルが大量にある人は、絶対にやめた方が良いです。
最初のうちは良いのですが、数十ギガ、ファイル数が数万～数十万を超えたあたりで速度低下。
しばらく停止、ちょろっと転送を繰り返す。
おそらく数日かけても、テラバイトのデータは転送が終わらないでしょう。
その間は対象HDDへのアクセスもおかしくなり、例えばファイルのプロパティを開くのに異常に時間がかかったり、おかしな値を表示したりする。
正直その動作は、壊れているのかと疑うほど。
転送を停止して、ずーっと待っていれば、正常に戻りますが……キャッシュのフラッシュが終わったからでしょうね。
以前のPCからデータを移動させない人、毎日コツコツ書き込む人、大きなファイルを置く人なら使えるでしょう。
逆に、バックアップ用でも小さいファイルが多いと地獄を見る事でしょう。
……４台まとめて買ったんですが、どうしよう？
メーカーがレビューに対してコメントしました (詳細)
日本シーゲイト_#2メーカー1日前
違反を報告
Mizu様
シーゲイトの製品をお選びいただきありがとうございます。
顕著な速度低下が見られるとのこと、ご不便をおかけし大変申し訳ございません。
恐れ入りますが下記コールセンターまたはウェブページでご一報いただけますでしょうか。
お役に立てる場合もあるかと存じます。
電話番号:0120-993-280 月曜日-金曜日 午前9時?午後6時
URL: https://support2.seagate.com/?language=ja_JP 小ファイル群を数十ギガ数十万単位でコピーする奴は普段使いとは言わねーわなw
ファイルエントリが多すぎるんだろうな
4GB単位くらいでzipとかに圧縮しながら送り込めば、普通に行けそうな気がするが
負荷が気になるんなら無圧縮でもいいし
CMRのHDD使ってた頃より、顕著に時間がかかるようでは汎用とは言えないだろうよ。
使いこなし、配慮が必要ならパッケージにでも明記しておかないとな。
SMRの最悪時動作＝仕様通りの動作・正常動作に見えるが、コールセンターに一報してなにがお役にたってくれるんだ？鉄狼に交換でもしてくれるのか？
>>242
レビュー改稿するなら交換しますよ、ってね 2.5インチのHDDでもうちでは5万時間越えて大丈夫だったのもあるから一概に寿命短いってこともないのでは？
それともただ単に運がいいだけかな？
>>246
サンプル数1なんだから、当たりおめでとう としか言えない。
少なくとも↓よりは幸運だわな
>>246
使用時間の現在値が1(残り1%)
SMART値的にはもう限界だ～ と言っているが、気にするかは個人の自由 やはり運がいいだけかな、他にAV-25シリーズとWDREDは2.5インチでも7/24時間対応だったと思う。
AV-25はレコーダーの換装用に幾つかオークション等で購入したけれど今の所壊れてない。
他にも日立のHCC系列の2.5インチも録画用の24時間対応だったのでそれも持ってるがそちらも問題なし。
500GB程度の容量だけどね。
倉庫用なら大丈夫だと思ってたらファイル数が多いと駄目か・・・
まだまだ改善が必要だな
ファイル数が多いと$MFTの書き換えが煩雑になるからかな
それならFATExなら速度はそんなに落ちないのかも
シーケンシャルで領域確保されてるファイルのランダムにピンポイント書き換えって、瓦が苦手としそうだもの
200MB～ディスク容量の12.5%まで膨らむ
>>251
今出ているSMRのHDDは買ってはいけないということだね。
技術の熟成に、あと2,3年はかかりそう。 使用時間なんかあったんか。
Linuxでcrystalなんちゃらが使えないから知らんかった
>>253
熟成でどうにかなると考える、その根拠がない ちゃんとMCは存在してたんだな
典型的な報告例が無かったから言ってるだけかと思ってたw
熟成じゃなくてドライブマネジド止めればもっとマシになる可能性があるんだろうけどなあ
>>259
そんなことしたら地獄が始まるだけでしょ
OSアップデートしないと絶対に動かない上に
OS毎に挙動が異なるようになるという LTO用のLTFSがある位だし、瓦に最適化されたファイルシステムが合っても良いと思うよね
IOの外付けHDD買ったら普通に海門の瓦だった
2TだからSMRはないだろうと甘く見てたわ・・・
fsもだけどSATAコマンドの瓦向け拡張があってもいいと思う
>>263
コマンド拡張してホストマネージドって話だったんだけどね。
コンシューマー向けには降りてこないね。(MicrosoftのOSが特に)
そのせいかWDは既存のコマンドでなんとかするべくTrim実装したし。 >>264
SATAコマンドはコマンド、規格で公(おおやけ)なもの
ホストマネージドはタコツボ化 >>264
WDのTRIMコマンドを発行したらどうなったか覚えてないのか？あんな動作するのを市販する方がおかしい。 SMRまだ持ってないし技術的なことわからないけどファイル数が多いとダメとかなら
pcレスのHDDデュプリケーターではどうなるのかな
今使ってるのだとクローン速度は中身のファイル総数や使用量に関係なくて
CMR3.5で大体１Tあたり4時間強
>>266
ごめん、どうなったのか知らないんだ。
自分は、WD60EZAZでhdparmでtrim発行して正常に終了したんだ。
データも正常だった。(60%ぐらいしか埋まってなかったけど) >>267
デュプリケーターは連続したセクタを連続してコピーだから、ファイル数は関係ないはず
コピーツールではなくファイルシステムを見るOS移行ツールなんかだとまずいかもね >>268
先月にWD60EZAZで
「LinuxでblkdiscardかUSB接続でTxBenchでTrim送ったら一瞬でデータ全部消えた
空き領域だけにTrim送るのはOSの対応待ちかな
まあSMRの配置が汚れまくったら簡単に回復できるのは便利なのかも」
とかあったんだけど、いつの間に大丈夫になったの？w >>270
blkdiscardはドライブ全体にTrim送るコマンドだから正常動作してるようにしか見えないが TxBench
TRIM
SSD/NVMeの全領域をTRIM機能によって消去します。 >>272
いや？TxBenchのTRIMをSSDにやっても全域消去されないよ？だから、SMRドライブで消えてビックリしたんじゃん。 >>273
TxBenchのTrimはデータ消去用の全領域実行と、
SSD最適化用の空き領域だけ実行の二種類ある
blkdiscardと一緒に書いてるんだから全領域の方やったんでしょ TxBenchはSecure Eraseでトラブルとロック解除できないという噂があったから使いたくないな
何十万のファイル数があろうがFastcopy使って転送すればexplorerでコピーするよか普通に速いんだが
（速いと言ってるだけで強制はしていない）
fastcopyだろうがランダムライトがシーケンシャルライトにはなったりしないので
MCが溢れるのはかわらんと思うが
>>279
Fastcopy使って試してないじゃんwww >>280
だとしたら何故 >>238 の人はfastcopyを使わず
サポセンもfastcopy勧め無いのか
何故SMRメーカーはそういうコピーソフトを自作しないのか
多分 SMR で遅くなるっていうのはお前が思ってるような話では無いんじゃないか？ >>281
おまえ本当に妄想でしか語らないのなwww
>>238なんて誰が読んでもFastcopyすら知らん情弱だってわかるだろ >>252
$MFT 以外にもディレクトリとか $Bitmap とか $LogFile とか書き換える必要あるからね。
もっとも、とくにまっさら状態に書き込むなら局所的なアクセスになるので
メディアキャッシュをうまく使えばなんとかなりそうなもんだけど。
WD のならここまでひどいことにはならないかも。
まあ、何年熟成させようと、使い込んで断片化が進んだ状態では物理的にどうにもならないが。
＞200MB～ディスク容量の12.5%まで膨らむ
その値は予約領域のサイズだね。12.5% は XP までの、200MB は Vista 以降のデフォ。
$MFT 自体は予約領域を超えても断片化しつつ空きクラスタがある限り際限なく伸びる。 >>282
>>238 の当人はともかくサポセンもメーカーもスレ住人も解決策を掲示出来てないところに
疑問を持ってみたほうが良いと思うけど
まあ、無理なんだろうな
一応言っとくとそのfastcopy程度では解決出来ない速度低下があるのが
CMRとSMRの違いなんだよ >>283
MCをうまく使えばってMCに乗っけて瓦書きを後回しにしてる時点で
MCが溢れたら遅くなる事は確定事項だからな
確かにWD方式ならマシにはなるだろうがMC溢れたら遅くなるのには変わらないわな >>284
でも、おまえFastcopy使ってないじゃんw
SMRのHDDも持ってないんだろ？www >>285
まっさらへの書き込みだと、データ本体だけではなく
$MFT と $Bitmap もセクタ順に埋まっていくんだよね。
$LogFile はどんな場合でも恐らくシーケンシャルに巡回使用。
それぞれをメディアキャッシュにキープし
バンド境界に達したところで瓦に書き出せば大したロスにはならない。
ディレクトリは断片化するし木構造のため書き込みが散らばる可能性があるので
ちょっと面倒かもしれないが。
要するに、まっさら状態へならメディアキャッシュが一度も溢れることなく
ずっと書き続けることも不可能じゃないってこと。
もちろん、通常の断片化に加え
CMR ならほぼ問題にならない $MFT 内のレコードの断片化が進めば
とんでもない量の書き換えが必要になる。
あくまで >>238 の「古いデータを移動させる時点でつまずきます」はさけられそうってだけ。 口は悪いけど>>286に実測値で反論しない限り>>284の負け
みんな前のスレの悪質な奴らの住処に戻らないためにも
否定派も肯定派ももう一度>>8を読んでくれ >>288
勝ちとか負けとか何だよw
これ以降レス禁止なお前 >>288
実測値！？お前には >>286 に実測値が見えるのか？
レス番号辺りを実測値と勘違いしてるのかな？ >>287
それファイルシステムの話だろ？
SMR（HDD）はファイルなんて知らないしファイルシステムを扱うOSは
SMRであることを知らないし、SMRはそんな無謀なアクセスをOSにさせる
コマンドを公開してないだろうから無茶な話だって >>288
前々スレ（Part.4）に↓のような実測レスがあるよ。
Windows10ではFastcopyよりエクスプローラーの方が高速ということらしい。
何事もおま環相対だからねえ。決めつけちゃうこと自体が危ういかもね～ w
=========
117Socket774 (ﾜｯﾁｮｲ 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の差ですね。
あとはディスクの内周まで書き込みが進んだ場合にどういう挙動になるかですね。
118Socket774 (ﾜｯﾁｮｲ 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前後出てる。 OS標準のコピーってなにか端折ってるんじゃないかと思ってしまうわ。
ベリファイ的な動作はコピー専用アプリと同じレベルの内容を実行してるんかな？
OS標準故の、動作的に最適化されて速い可能性もあるから
コピーアプリの方が遅いのはおかしいなんていうつもりはないけれど。
ログを残したいってのもあるし、
自分は移動をよく使うのでファイル一個ずつコピーしてベリファイして元削除って動作ができるツールは
OS標準コピーの速度にはないメリットを感じる。
自分がコピー用アプリを使い始めたきっかけを考えると、
TB単位やら数千ファイルといった規模の大きなコピーだとOS機能では遅くなったことが発端だなぁ。
使い始めたら数々の便利機能も手放せなくなったから
仮に速度面が改善したとしてももう戻れないけど。
バックアップみたいな速度が最優先ではない場面ではOS機能コピーで完了するのはありえないとも思うし。
>>206
WD, SGそれぞれのSMR HDDの動作検証の続きです。
---
OS
Win10 pro 64bit
コピー方法
エクスプローラの標準コピー
所要時間を測定
対象HDD
WD60EZRZ(CMR)
WD60EZAZ(SMR)
ST6000DM003(SMR)
いずれも同一の外付けHDDケース(USB3.0)に入れた状態での測定です。
[1] Format直後のHDDへのデータ書き込み
コピー元
XQD
121GB(130,753,500,967B)
6567コ
1ファイル19MB程度
カードリーダ SONY MRW-E90(XQD)
WD60EZRZ(CMR)
14m45sec
WD60EZAZ(SMR)
11m27sec
ST6000DM003(SMR)
18m13sec
[2] 1.3TB程度使用時のHDDへのデータ書き込み
コピー元
XQD
121GB(130,749,943,824B)
6542コ
1ファイル19MB程度
カードリーダ SONY MRW-E90(XQD)
WD60EZRZ(CMR)
15m52sec
WD60EZAZ(SMR)
12m39sec
ST6000DM003(SMR)
19m57sec >>297
今回は各HDDについて1.3TB程度までデータが書き込まれた状態でのテストです。
Format直後のHDDへのデータ書き込み時に比べて、いずれも少し書き込みに時間がかかるように
なっただけで、目立った変化はありませんでした。
またいずれも途中で極端に書き込み速度が落ちるようなことはありませんでした。おそらくは
メディアキャッシュは経由しているんでしょうけど、滞ることなくスムーズにデータが書き込ま
れているものと思います。 >>294
というかSMRとCMRで時間があんまり変わらないって事は
殆ど瓦書きによる待ちは発生してないんだな
まあ1ファイル20MBもあったら数倍時間がかかる程度だから妥当ではあるか >>299
HDDを半分以上使った状態になると、瓦書き込み特有の遅延が出てくるのではないかと予想してます。 >>297
ちょっと裏話。
1.3TBまで使用した状態を作るために、最初にコピーしたデータ(121GB)をコピー元として
HDD内でコピーを繰り返しました。
3個分または4個分をまとめて並列でコピーさせたんですが、WD60EZRZ(CMR)とWD60EZAZ(SMR)
は合計の書き込み速度が100MB/s程度で安定していてスムーズでした。
一方、ST6000DM003(SMR)は合計の書き込み速度が1～130MB/sで変動しまくりで安定し
なかったです。書き込み量が60%を超えてからは合計書き込み速度10MB/s以下が続きま
した。このあたりもWDのSMRとSGのSMRとで挙動がぜんぜん違いました。
またこのコピー中に、WD60EZAZ(SMR)とST6000DM003(SMR)については、OSからHDDが
見えなくなってコピーが中断するという事故が数回起きました。しばらくすると再認識したの
で再開させてます。これは原因はわかりません。3個分または4個分をまとめて並列でコピー
とか無茶させたのがいけなかったですかね？ ちなみにWD60EZRZ(CMR)ではこのような
事故はありませんでした。 >>300
多分あんま関係ない
SMRの遅くなる要因はメディアキャッシュに乗った書き込みデータがいかに瓦書きで捌けるかで
捌き安さはデータサイズに反比例するのが一番支配的なはず
>>297 の場合1ファイル1MBにして120GB分コピーするととんでもない時間がかかると思うよ
何倍かかるかは予想も出来ないが >>303
HDDを使い切る直前まで、瓦書き込み特有の遅延が生じないのであれば、自分としては
データ保存用のHDDとしてSMRを受け入れることが出来るようになるので、助かります。
あくまで転送速度という観点からは、ですけどね。信頼性はまた別です。
ファイルサイズが1MBでの検証は機会があったらやってみます。 >>297,302
情報投下サンクスです
シングルストリームのコピーでは現状SMRはMCのデータも停滞する事なく吐き出せて全く問題無さそうですね
普段複数のコピー元から書き込むマルチストリームなんて録画用位しか考えられないし、倉庫用なら良いか
システムにSMR使おうとなんて考えなければ
リンクダウンについて、もしかしたらUSB変換チップとの相性かもしれません
高負荷(内部的に)時にコマンド応答時間がCMRよりも長くて、変換チップに未接続と判断されたとかありそう >>305
結果的にこれ、マルチストリームの検証みたいにもなっていたんですね。ただソースが同一HDD内
にあるという点では録画用途とはまたちょっと状況が違いますけど。リンクダウンの件を別にすれば、
WD60EZAZ(SMR)はこのようなマルチストリームコピーでも目立った異常は見られなかったですけ
ど、ST6000DM003(SMR)は不安定かつ後半は著しい書き込み速度の低下がありました。
リンクダウンの原因についてはそういう可能j性もあるんですね。ありがとうございます。 >>288
実測値が絶対的価値を持つのは、どんな環境どんな場合でも傾向が変わらないときだけ。
SMR は使い方によって挙動が大きく変わるので、
具体的な数値を出したところで数例程度では勝ち負けを明確にすることはできないよ。
てなわけで、ここはメーカーから公表された仕組やユーザーからの報告を元に
あーだこーだ考察するのがメインの隔離スレだと思ってる。
長くなりがちなので興味ない人には邪魔になっちゃうからね。 >>292
いや、ファイルシステムを把握する必要はないよ。
与えられたコマンド通りの結果になるように振舞えればいいだけで、データも管理領域もない。
まっさらに細かいファイルを大量に書き込むという今回のケースにおいて、
それぞれのライトアクセスはほぼシーケンシャルになるので
アクセスパターンからそれを察知し適切に対処できればうまくいくだろうって話。 >>295
エクスプローラはベリファイなんてしてないよ。
FastCopy だけベリファイオンだったら不公平もいいとこ。
まあ、それだと倍近く差が付くはずなのでないとは思うが。
エクスプローラはシステムキャッシュを使うので、コピーが完了したように見えても
実際には遅延書き込みが続いてることは考慮してるのかな。
FastCopy はシステムキャッシュを使わないのでそういうことはない。
で、FastCopy が速いのではなく「昔はエクスプローラが遅かった」が正しいんだと思う。
システムキャッシュの挙動やエクスプローラ自体の改善により今は大差ない。
ただ、作成日時をコピーしてくれないのがなあ。
考え方によっては現在日時になるのが正しいこともあるんだろうけど、
自分としては完全な複製が欲しいことがほとんど。 >>304
残量自体より空き領域が断片化してるかどうかがポイント。
まあ、まっさら領域が大量に残ってるうちはそちらが使われることも多いので、
本当の勝負は残量が減ってからだけど。
削除しないならそもそも問題ない。
>>305
リンクダウンはそうだろうね。
どんなに無茶をさせようと本来あってはならないこと。
安心できるケースの情報も必要になってくるなあ。 >>309
FastCopyを使ったのは1月の検証時ですけど、べりファイについては特別設定は
してなかったと思います。デフォルトではオンですかね？ だとするとベリファイを
オフにした検証もまた必要かも知れないです。
OS標準コピーの遅延書き込みは考慮してないです。この場合の遅延書き込みって
時間的にどれくらいあるものですか？ 遅延書き込みが続いてる場合はHDDのア
クセスランプは点滅しますよね？ 今度やるときはアクセスランプを注意して見てみ
ます。 >>308
MC内で同じバンドの書き込みデータはまとめれば良いのにって話かな？
まあ、それをやってるかやってないかは知らないが、それ位はやってるんじゃないかね >>313
やっても大丈夫、SSD見たいに劣化を促進させたりはしない しかし、数日の作業時間は覚悟しないとだめだ
さらに意味あるのか？
瓦ブロックをぐちゃぐちゃにするだけかも
WD使いならtrim発行するだけで良さそう(データ削除目的の全領域trimじゃないよ、念のため)
デフラグなんかやったらそれこそいつまで経っても終わらなそうだが
>>315
あーたしかにWD方式だとあんまり良くないかもな
物理と論理アドレスがかけ離れてるらしいから
論理アドレス揃えても意味無さそう
海門式なら問題ないだろうけど >>292
コピーツール側はファイルシステムを知った上でOSを使い、OSの汎用ドライバはSATAコマンドを使い、SATAコマンド連続領域の予約を知ってる
だから、
・メタデータとデータの扱いは別になり、データはMCが効く
・その際、断片化を低減させる「連続領域の予約」を使う
が実装されてるんだわ
ドライブのファームと今回のコピーツールを混同しちゃいかんよ >>319
書き間違えた
誤・メタデータとデータの扱いは別になり、データはMCが効く
正・メタデータとデータの扱いは別になり、メタデータにはMCが効く >>318
WD方式と海門式があることをこのスレで初めて知りました。 >>321
挙動等違うのでそーなんじゃないかという推測だけどね
実際中の処理は非公開だし 力説してる人いるけど、CMRタイプのHDD買えばいいだけの話だよね
まだ売ってるんだから
>>319
いや書き込みデータを MC に置くかどうか決めるのは OS ではなくHDD（SMR）だと思うが
少なくとも SMR が生まれる前からあるOSやSATA汎用ドライバが
MCを知ってるわけが無いわけで >>323
こいつら妄想したいだけの暇人だから正論言っても無駄なのよ >>324
データとは離れたアドレスに置くからMCだよ >>324
あと、ドライバじゃなくてドライブのファームがMCの使用不使用を決める >>323
SMRスレで何言ってんの？
そのうち一般用はSMRに全て変わるんだから、今のうちに情報を集めるのがこのスレの主旨だよ
>>325
お前も得意気に妄想を語る一人だろうがw >>329
ああごめん、そこは合ってるから引っ込めるよ
本筋は>>292に対するツッコミとして、どこからどこへリクエスト行ってるのか分かってない
って事を言いたいのよ >>307
いい加減おかしな論法で負け惜しみを言うのはやめろ。議論の価値は全く違う
実測値に基づく建設的な検証議論>>>越えられない壁>>>公式情報に基づくが理論上だけで勝手な推測と思い込みばかりの否定し合い 俺様正解で相手を打ち負かすことが目的になっているような状況でなければ
推測論だって価値は有ると思うけどね。
そもそも実測からの検証だって内部動作なりの資料が公表されてない以上、
結局は推測が付きまとうんだし。
ぶっちゃけ俺様正解な人からしてみれば、
相手の意見を打ち負かすことも建設的で価値があることだと思ってるんじゃね？
打ち負かすというよりも教えてあげているみたいな意識なんだと思うけれど。
>>311
FastCopy のベリファイはデフォルトオフだった気がする。
遅延書き込みの時間は環境によるとしか。
HDD への書き込みが 100MB/s でキャッシュに 4GB 使えるなら
計算上 40 秒かかるケースも有り得ることになるけど、
実際にそこまで溜め込むことがあるのかはうちでは確認できそうにない。
タスクマネージャを詳細表示にしてメモリ構成のバーを見てれば挙動がわかると思う。
SMR ならディスクの平均応答時間も面白いかも。 >>312
それはやらないと話にならない。
そしていくらファイルが細かかろうとまっさらへの書き込みならアクセスは局所的になり
十分さばけそうなのに破綻してしまったのはなんでだろうってのが話の発端。
どうもシーゲートはメディアキャッシュから瓦への書き出しを放置しがちで
一杯になってから慌てて対処しようとしてどうにもならなくなってる感じ。
ディレクトリ等繰り返し使用されるものもあるのである程度はとどめておくのも有効だけど
余裕のあるうちに使われなくなったものからさっさと吐き出さないと。 >>319
＞・その際、断片化を低減させる「連続領域の予約」を使う
って何？ ﾜｯﾁｮｲ d8c5-TlgA と同一人物っぽいので
ファイルシステムがクラスタを割り当てる動作と混同しているとは思えないけど、
ひとつのコマンドで複数のセクタをまとめて処理するってことなら
最大サイズでもバンドサイズに対して小さ過ぎるのであまり意味ないかも。
コマンドレベルなら Force Unit Access がどれが管理情報か判別するヒントになるかも。
本来はキャッシュに残さずきちんと書き込みなさいという指示だけど、
メディアキャッシュなら不正終了しても消えないので使ってもいいはず。
というか使わないと壊滅的な遅さになりそうｗ >>332
まさに論について「俺様正解」になってる人に何を言っても無駄だよ。
>>307 でも考え方の問題点を指摘したのに、それについては何も反論せず
自分が正しいと繰り返すだけな人が論を語るなど、これほど滑稽なこともそうそうない。 >>335
> ・その際、断片化を低減させる「連続領域の予約」を使う
これはSATAのコマンドだよ
わかってないの？ >>335
ああ別の人かな
だとしたらすまん
OS/ツール側が発行するSATAの標準的コマンド
だからCMRを想定していて、かつSMRのドライブなら可能な限りバンド直書きになる >>337-338
けっこう調べたんだがそれらしいものは見つからなかったんだよ。
正式なコマンド名わからない？
「これから予約した連続領域に書き込みますよ」という宣言なら確かに役に立つが、
SMR 登場以前にそんなものが制定されていて
Win 等が活用しているとはとても思えないけどなあ。 最大32MiBらしいけどのDMA転送のことじゃない？
そもそもファイルシステムを知ってるはずのOS側からの書き込み指示は
SATAコマンドを頼らずとも連続領域に書き込めるんだし。
空いていればだけど。
だからこそアドレス再配置が行われるWD方式の問題点が出てくるんだし。
ディスク上のどこに何を書くか判断し指示を発行するのはHOST側、
その指示を元にディスクは処理するだけ。
ディスク内での処理の過程で勝手に工夫してるのが各種キャッシュ構造でありSMRの処理。
>>306
引き続きHDDをもう少しデータが書き込まれた状態にするためにコピーをしたんです
が、WD60EZAZ(SMR)では1フォルダのみのコピーでもリンクダウンが発生しました。
同一HDD内でただコピーをしただけでリンクダウンが発生するのではお手上げです。
今回はソースを別のHDDにすることで作業をすすめてます。ソースが別のHDDであ
ればリンクダウンは発生していません。
同一HDD内でコピーをしただけでリンクダウンが発生するのでは、運用上困りますね。
データ保存用のHDDではそのような操作はしませんが、作業用のHDDでは頻繁にや
る操作ですから。
ただ今回は外付けHDDケースに入れた状態での現象なので、SATAに直結した状態
だとどうなのか確認しないとなんとも言えません。前述のように原因が外付けHDDケー
スにある可能性が高いと思います。 >>334
そらユーザーが使ってる時に裏で頻繁に瓦書きなんてされたら
常用時のMCへの書き込みが遅くなるからな
>>238 みたいな一万人に一人いるかいないかの人の為にそれ以外の人の速度を1割落とすみたいな
選択は取れないでしょ 万人に一人というか一度入れたら何があっても決して動かさない人ならいいが、
HDDの中身の整理整頓や入れ替えでHDD丸ごと移動をくり返すと結構出てくるケース
>>343
どう整理しようがまず数十万ファイル持ってないと起きないわけで
そんなにもってる人が極稀だっていう
っつーか数十万ファイルって何のファイルだろうな？
画像ファイルだとしたら探すだけで日が暮れて
一個一個見るだけで年が明けそうだが >>344
Webページをメモ的にどんどんローカル保存していくとあっという間に溜まりますよ 記憶域パリティ（RAID5）をドライブ4台で作成して、
数GB程度の大きいファイルをGbE経由で書き込んだんだが…
ST4000DM004：30-40MB/s
WD40EZRZ-RT2：90-110MB/s
WD60EZAZ：80-100MB/s
※合計100GB程度のファイルをコピーしてOSのキャッシュ切れてから安定した速度
なんで海門だけこんなに遅いんだろと思ったんだが…
上の人の書き込み見るとそういう仕様なのかね
それにしてもあまりに遅い
パリティは双方向ミラーSSD使って記憶域階層にするとGbE上限に張り付いて快適になるぞ
>>345
それなんの為に保存するの？後で見るため？
それともブラウザのパフォーマンス向上のためのキャッシュ的な用途？ >>346
なんでGbE経由で書き込んだのに合計書き込み速度がGb/s超えてるんだ？ >>349
あ、何でもない
それぞれ4本づつ揃えてraid5組んだ結果なのね
ブルジョワジーなのね 自作板のSMRスレに書き込むような人間がなんでわざわざSMRドライブでRAID組むのか不思議で仕方ない
自作板に書き込んでるって時点でWeb検索なりしてSMRについて調べてるだろうし
SMRを使ったシステムに関してSMRスレに書くのは当たり前ではないのか…
>>346
おなじドライブマネージド言うても賢さが段違いやな むしろdrobo 以外にSMR不可って言ってるところあったっけ？
>>297
WD, SGそれぞれのSMR HDDの動作検証の続きです。
---
OS
Win10 pro 64bit
コピー方法
エクスプローラの標準コピー
所要時間を測定
対象HDD
WD60EZRZ(CMR)
WD60EZAZ(SMR)
ST6000DM003(SMR)
いずれも同一の外付けHDDケース(USB3.0)に入れた状態での測定です。
WD60EZRZ(CMR)
[1] Format直後 14m45sec
[2] 1.3TB程度使用時 15m52sec
[3] 2.4TB程度使用時 14m30sec
WD60EZAZ(SMR)
[1] Format直後 11m27sec
[2] 1.3TB程度使用時 12m39sec
[3] 2.4TB程度使用時 13m59sec
ST6000DM003(SMR)
[1] Format直後 18m13sec
[2] 1.3TB程度使用時 19m57sec
[3] 2.4TB程度使用時 21m29sec
コピー元
XQD
121GB
1ファイル19MB程度
約6500コ
カードリーダ SONY MRW-E90(XQD) >>357
今回は2.4TB程度使用時のデータを追記しました。
あまり目立った変化はありませんが、WD60EZRZ(CMR)は過去2回よりもなぜか書込所要時間が短く
なりました。この検証の目的はSMR HDDの挙動の確認なので、CMR HDDのこの挙動については見
過ごすことにします。 >>339
お手数かけてすんません、出てこないや
ないもの前提でグダグタやってたなら恥ずかしー
てっきりfalloc実装にあるかと思っていたのだが
付記
kernelnewbies.orgのfallocから始めて、
ata.wiki.kernel.orgあたりまでチェック
分かったのはMarvellのコントローラーのバグ回避のみ SMRがゴミなのでは無く死門がゴミだけだったという事が判明
という事でこのスレ終了 次スレいらないよね
>>360
「またこのコピー中に、WD60EZAZ(SMR)とST6000DM003(SMR)については、OSからHDDが
見えなくなってコピーが中断するという事故が数回起きました。しばらくすると再認識したの
で再開させてます。これは原因はわかりません。3個分または4個分をまとめて並列でコピー
とか無茶させたのがいけなかったですかね？ ちなみにWD60EZRZ(CMR)ではこのような
事故はありませんでした。」
こう言ったところを見逃せないわけで、WDもSeagateも問題あると思います。
BDレコーダーなどで複数番組を録画するとかよくあることなのでユーザーが録画用途に購入した場合、録画失敗が続出でしょう。 >>361
これ注意していただきたいのは、事故が起きた時の状況は同一HDD内にあるデータをソースとして
コピーした場合なんです。さらに言えば、並列コピーではなくシングルでも事故りました。要は同じ
HDD内にあるデータをソースとして、同じHDDにコピーすると事故るんです。コピー元(ソース)を別
のデバイスにすれば大丈夫でした。
そういう意味で録画時の挙動とは違います。
ただ同一HDD内でのコピーで事故ること自体はやはり問題でしょう。使用しているHDDケースに原
因がある可能性があります。 >>362
そうなんだ。録画が済んだ番組をCMカットとか編集した場合事故りそう。
あと世代コピーするバックアップアプリとかそういうのでもやばそうな感じ。 >>362
SMR 内でリードの負荷が増えることによりMCから瓦書きで書き込みデータが捌けなくなって
MC溢れが起こってOSからSMRへの書き込み処理の応答が激遅になり
HDDケースのタイムアウトに引っかかって切断とかかね ブロック単位で書き込む不自由さもさることながら
データを重ねることによるデータ化けも怖い
素のデータ経年劣化も早いのではないか
瓦ブロック容量とSATA３速度とシーク速度でバッファ容量を決めているのだろうが
いって帰っての意地悪テストまではバッファ容量を考慮していない
>>340
＞最大32MiBらしいけどのDMA転送のことじゃない？
とりあえず Win7 はコマンドレベルでは 256 セクタ = 128KiB が最大らしいので
バンドサイズに対して小さ過ぎる。ヒントにはなるかもだけど。
＞そもそもファイルシステムを知ってるはずのOS側からの書き込み指示は
＞SATAコマンドを頼らずとも連続領域に書き込めるんだし。
どの領域を使うかはクラスタ割り当て時に決定してて、
書き込み段階にどうこうできるものじゃないしね。
＞だからこそアドレス再配置が行われるWD方式の問題点が出てくるんだし。
これ、決め付けは危険だと思う。
Trim があるということで NAND のそれを連想して噂が広まったんだろうけど、
バンド内で必要のなくなったセクタが判明するだけでも SMR 処理的には色々役に立つ。
NAND と違いシークと回転待ち時間があるのでアドレス変換は害も多いよね。
ファイルシステムはなるべく連続領域になるようクラスタを割り当てるのに無駄になっちゃう。
まあ、埋めるまでのパフォーマンス優先で
部分削除とかしたあとのことなど知らんって方針もありっちゃありだけど……。
いきなり末尾付近の LBA に書き込むテストした人いないかな。
それで外周の速度が出ちゃうようなら論理アドレス≠物理アドレスが確定する。 >>362
そのケースがあまりに敏感過ぎる感じだよね。
RAID 対応の HDD には安易に RAID から外れないよう
長時間無反応にならないような仕組があるけど、
デフォは７秒とかなので業界的に１０秒くらいが基準なのかな。
FastCopy 使えば読み書きを同時に行わなくなるので回避できるかも。
前に、今はエクスプローラも遅くないと書いちゃったけど、
同一 HDD 内コピーでは FastCopy のほうが安定して速いはず。 ファイル数が数万あるかどうかは分かりませんがSteamのデータ置き場にSMRを使うのは無謀でしょうか？
ファイルが大きければ大きいほどSMRの短所が見えなくなる
動画等の置き場には最適
ただし重ね書きすることによりデータ保存期間が短くなるかもしれん
重ね書きしたデータは多値記録していることと同じなのではないか
ゲームには迷わずSSDでしょ
しかし、数万〜数十万単位の小容量ファイルコピー実際やった人あんまりいないんだな
適当に買った1TB外付けHDDがWDのSMRだったんだけど
確かにファイル数と容量が一定のライン越えると殆ど止まってるレベルで遅くなるよ
でも大体の限界値探ってファイル数と容量ほどほどにおさえながら
何回かに分けてコピーするとトータルでもCMRより早く済んだりする
よくわからんわ
>>365
HDDの読み書き頻度はHDD破損には関係ないってグーグルが言ってたから
そんな事は無いってのが定説なんじゃね
俺の推測だと読み書きによる経年劣化は理論的にはあるけど
他の箇所が壊れる方が圧倒的に早いから問題にならないとかかなと >>367
いやWD方式は論理≠物理アドなのは>>1辺りのpdfにもあったと思うので確定かと >>367
シーケンシャルアクセスが遅くなるのは
wd方式では約30MBのバンド単位でアドレスが区切られるはずで
100MBの毎に3回位シークが増えてもそんなに速度に影響ないんじゃね
っていうような前スレのレスで俺は納得してる >>367
>>1 の東芝のpdfの30と31ページに渡って物理と論理アドレス改変の記述があるな
つまり東芝もWD方式 >>370
>>372 さんも言ってるように書き換え回数で劣化する程やわじゃないし、
データの保存性というか書き込み品質の面でも
CMR も前のデータを消したりせず上書きしてるだけなので変わらないよ。
懸念があるとすれば、書き込み中に振動でヘッドが揺れたときに
隣のトラックのデータを劣化させてしまう危険が高まるのと（考慮はしてるらしい）、
突発的な磁性体劣化で読めなくなったときに
サルベージできる可能性が下がりそうってくらいかな。 >>374
セクタ単位でぐちゃぐちゃになったらひどいことになりそうと思ってたが、
そうか新たに作られるシーケンシャルの断片化はバンド単位か。
$MFT なんかはとんでもなくバラバラになりそうだけど、アクセス頻度で管理してれば
よく使う部分はメディアキャッシュ上にキープされそうだし大丈夫か。
問題になりそうなのはランダムライトで埋めたあとシーケンシャルに読み出す場合
……って、まったく思い付かないなｗ >>371
いや多分それが素晴らしく正しいSMRの使い方だよ！
何も知らずそこに辿り着くとは天才か？w
SMRは本来小さいデータを書く時に瓦書きをという
CMRの数倍から数百倍も時間のかかる書き方をしなければならない
そこで瓦書きをしなくて書けるメディアキャッシュ（MC）という領域を数十GB程用意して
瓦書き対象となるデータを一時的にそこに書いて後回しにする事により誤魔化している
なので大量の小さなファイルを書き込もうとするとMCがいっぱいになってしまい
MCから瓦書きをして空きが出来るまで書き込みが出来なくなる
それが止まってるレベルで遅くなる正体かと うーーん・・・
重ね書きというのはトラックの隣同士で物理的に重なることを言っているのだが・・・・
容量を二倍程度に増やしているわけだからトラック同士で相当重なっているはず
だとすれば重なった部分の磁気レベルは2bitで多値記録されていることになりませんか？ってこと
そうすると多値記録された磁気を読み取ることができる限界時間は１bit記録されたそれにくらべれば
成績が悪くなるのでは？と危惧している次第でして
>>377
なんか難しく考え過ぎじゃね？
確かに$MFT の分割数は増えるだろうがその影響の実態は30MB毎にシークが一回増えるだけなわけで
そんなに影響が懸念される程の事？
というか案外影響無いから今動いてると考えた方が自然な気がするが >>379
重なった部分は後に書いたデータとしてしか読まれないと言ったら少しは誤解が解けたりする？ >>380
いや、懸念は大分消えたけど、アドレス変換はセクタ単位のはずだよ。
NAND のように書き換え回数を分散させる必要もなければ
消去に時間がかかるので事前にやっておこうってのもないので
バンド単位じゃ意味ない。
なので、意図的に作れば LBA 的には断片化してないのに
物理的には１セクタ単位でバラバラという状態もありえる。 >>379
説明下手かw 多値記録の引き合いは悪手だぜぇ
メタルテープにノーマル対応の機器で上書き録音した見たいな事を言いたいんだろっ
ま、SMR初期の茂出してたアーカイブHDDはHDD-Rと呼ばれる位書き換えた後の挙動が怪しかった
不良セクター爆増とかしたらしい
なんかその推測当たってそうだよね
更地に初めて書くときは良いけど、書き換えると前の極性の影響で書いた磁気強度が変わってくる見たいな
保持性能に影響しそう >>383
いや、だから CMR もただ上書きしてるだけなのになぜそういう結論になるんだよ。
消去ヘッドなんてないぞｗ
テープで例えるなら、フェリクロームのように
隣接トラックに多少転写しやすいってのはあるかもしれない。 >>378
う〜ん、それにしても最終的に同じだけの小容量大量ファイルコピーをするのに
一気にやらず小分けにするだけで作業時間まで含めたトータルコピー時間が
数分の一で済んじゃうってのはどうなってるんだろ？
何か非効率な処理がなされてるとしか思えんのだが >>382
俺が海門方式とWD方式を理解するのに役立った前スレのレス集
WD方式はトリムの要求とMCからの瓦書き処理の高速化をトレードオフしたって事だろうと思ってるが。
13 Socket774 (ｽｯﾌﾟ Sd0a-9csk)2019/02/26(火) 14:18:57.67ID:IsNMmtJmd
前スレの
>>816
海門のSMRはバンド上書きで論理＝物理アドレス。トリム&ガベッジ不要無用。
WD方式は新規バンド別書きで論理 ≠物理アドレス。トリム&ガベッジ必須常用。
SMRが～ と云ってもメーカーが違えば中身は別モノなのよね～
312 Socket774 (ｽﾌｯ Sd32-+BDI)2019/03/08(金) 13:03:54.58ID:GR0mKxgUd
>>293
ベリファイ有りとして、MC→瓦書き換えの動作
seagate
(0.MC読み)
1.瓦読み
2.マージして新MCに書く
3.ベリファイ
4.新MC側有効化、旧MC/瓦無効化
(5.MC読み:連続処理するなら省ける)
6.瓦書き
7.ベリファイ
8.瓦側有効化、新MC無効化
WD
(0.MC読み)
1.瓦読み
2.マージして新瓦書き
3.ベリファイ
4.新瓦有効化、MC/旧瓦無効化
・・重そうだけど、こんだけ違うとWD/seagate/CMRの比較負荷試験を上手くパターンを考えてやったら何か分かる気も？
あ、seagateの5.は無駄処理ですが、中断可能ポイントと考えると混んできた場合の瞬間負荷をWD方式と同程度に抑えられると思い()で書きました。余計ややこしくなりますが・・やっぱりメーカに説明して欲しいw
364 Socket359 (ﾜｯﾁｮｲ 12ef-gi2a)2019/03/11(月) 21:53:08.83ID:a+FBumYJ0
いくらTrim使うって言ってもさ、
SSDはどんな位置でもレイテンシ変わらんけどさ、
HDDだとデータ連続してないと不利だよねぇ…？
使い込んでいくとどんどん非連続になっていってシークばっかりになったりしないのだろうか
WDがそんな馬鹿な設計してないとは思うけど…
369 Socket774 (ﾜｯﾁｮｲ 1644-4spV)2019/03/12(火) 02:36:14.94ID:pevIXGO+0
>>364
今のHDDの読み出し速度が200MB/s程度とすると、
30MB単位でフラグメントすると最悪で毎秒7回ほど遠いシークが発生するけど
その程度なら気にしないという判断かもしれないよね。 WDはガベッジ必須ってほんとうかね？
常にアクセスされている鯖のような運用状況でガベージする暇なんて作り出せるかね？
>>389
作り出せない、その様な用途には瓦は向かない 俺もそもそもガベッジは要らない気はしてるけど
まあ、トリムは必要だろうなと思うので
>>385
小分けにするだけで効率化が効く＝小分けにしない使い方では非効率。seagateのチューニングではその使い方は良くないって事ですね。
ファイル数が多くサイズが小さい適正
CMR>WD方式SMR>seagate方式SMR
大ファイル適正が逆になれば良いんだけど、値段補正を含めてもそうとは言えないのが残念。 そう
効果を発揮する条件が限定的でSSDのようにブロック制御に縛られることもない
HDDのガベコレはどう考えてもコストに見合わない
>>393
えっ、WD方式はガベコレ必須だろw
じゃないとわざわざtrimなんか実装しないって
結局破綻を先延ばしにしてるだけなんだからさぁ
まぁ、その間に空き時間やOSがtrim発行すれば更に先延ばしにできる訳だけどな >>387
もちろん書き換えはバンド単位だけど、アドレス変換はセクタ単位。
NAND の場合、>>382 に書いた理由からブロック（バンドに相当）単位でも意味があり
初期にはそういうものもあったかもしれないが、
効率が悪過ぎるので今の SSD 等ではページ（セクタに相当）単位で変換してる。
SMR の場合、セクタ単位で変換しないと意味がない。
書き換え単位と変換単位が異なるからこそガベージコレクションが必要になる。
なので、「30MB毎にシークが一回増えるだけ」では済まないってこと。
実際に $MFT は相当バラバラになりそうだけど、
まとめて読むことなど chkdsk や一部のデフラグソフトくらいなのでまあ問題ない。
$Bitmap にも同様のことが起こり、こちらは認識時間に多少影響するかもしれない。 >>388
それ、もしベリファイしてるとしたらという話の流れでのものだということを考慮しても
無駄が多い気がする。
ただでさえ遅くなるのが懸念されるのにベリファイなんてしてないと思うが。
シーゲート式で一度メディアキャッシュに退避する理由がわからない。
１．瓦から RAM に読む
２．MC から RAM にマージ
３．RAM から瓦に書く
でよくない？
WD のほうのはガベージコレクションの動作であって、
通常の吐き出しはメディアキャッシュ内でバンドサイズ分チョイスして
空きバンドに書き込むだけということを考慮しないと妥当な比較はできない。 >>395
WDは物理-論理アドレス変換を導入してユーザー処理時間を削減したいんだよ、たとえ総合の処理時間が増えたとしてもね
>>397
支持する
メーカーから正式発表がないのであくまでも推測だが、合理的に考えると大体下記の動作だろう
書き込み(茂、WD共通)
1.瓦バンド+α分 RAMにバッファ
2.メディアキャッシュ(MC)に書き込み
3.連続アドレスのデータが送られてきたら、MC経由せず瓦バンドにダイレクト書き込み
MC容量が逼迫したら上記と平行して処理(茂の場合)
アドレスというか処理の粒度は瓦バンド単位ですむ
4.既書き込み済み瓦バンドからRAMに読む(読む瓦バンドはMC上にデータがヒットしている物を選定)
5.RAMからMC上にマージ
6.マージ済みデータを瓦バンドに書き戻し
上記と平行して処理(WDの場合)
処理の粒度はセクター単位
4.論理アドレスが連続していないデータも瓦バンドに書いてしまう(要アドレス変換)
5.既書き込み済み論理アドレスのデータが来たら、新しく書き込んだ瓦バンド内のデータを参照するようにアドレス変換ルックアップテーブル(LUT)を変更(実体はMC上、RAM上にコピーか)
ガベージコレクション
6.既書き込み済み瓦バンドからRAMに読む(読む瓦バンドは失効してるデータが多数ある穴空きバンドを優先して選定)
7.連続アドレスになるように再構築して未記録瓦バンドに書き戻し、バンド未満のデータはMCに書き戻し、LUT変更
(既書き込み済み瓦バンドとして再利用可能に)
物理アドレスの連続性にどの程度拘るかは不明、下手すると延々デフラグ状態に陥る 修正
×(既書き込み済み瓦バンドとして再利用可能に)
○(既書き込み済み瓦バンドは、未記録バンドとして再利用可能に)
>>397
> ３．RAM から瓦に書く
この最中にHDDの電源が落ちると書いてるバンドのデータが復旧不能になるのでそれはありえないと思う
>>388 はどこでHDDの電源が落ちても完全なバンドのデータが残っていて
再起動後に問題なく動作するようになっている RAMにみんなあるということはバンドに書かれ済みのデータはもう不要なデータ。
電源断でデータが飛んだとしても問題ないでしょう。
もちろんRAM内のデータも飛ぶわけだが、
書き込み途中のRAM内のデータが電源断で飛ぶことはSMRに限らず普通に存在するリスク。
WD60EZAZを買ったので、自分の中でSMRの一番の懸念材料だった
消しちゃったファイルを復元できるかやってみたけど需要あるかな？
>>401
そういう問題ではなく
例えば瓦が3段だった場合下段だけ書くと元々書かれてた中段のデータは消失するわけで
その状態で電源断するとその中段のデータが他に書かれてない限り復旧出来なくなる
だから >>388 みたいにまどろっこしく元のデータを移動させながら書く必要がある バンドのデータがみんなあるんだから途中から書くなんてことはしないだろ？
仮に途中からにしても、その瓦トラック以降のデータがみんなあるときにだけ直書きすればいい。
WD60EZAZは大量に書き込むと終わってもかなり長時間バックグラウンドGCをガリガリやってる
>>404
そうだよ。バンドを丸ごと瓦書きで書き換える時の話だ
その際に下段中段上段と順番に書いていくわけだが
下段を書いた直後は一時的に中段のデータは瓦からは読めなくなる、というかぶっ壊れる
当然通常動作ではその後にRAMやその他の領域から中段のデータを読んで書くので問題ないが
中段を書く前に電源断されると中段のデータがRAMにしか無かった場合は復旧不能でデータロストとなる
だから瓦書きの前に書き換え対象のバンドのデータをMCにバックアップしておく必要がある ID:14QRU2+10 さんが追加回答されてますが、せっかく長文書いたので張っときますw
>>401
低レベルまでsync待ちすれば0に出来ると言う話を横に置いても、書き込み途中と言う状態はCMRでは最初の一回だけ。
ところがSMRでは自データの初期書き込み時のMC→瓦時だけでなく、自分やバンドメンバの書き換え時ですら発生します。言い換えると自分の書き込みに関係なく何回も書き込み途中が発生する(しかも定義からしてsync待ちは不可能)事になります。
そんな仕様なのに、電源突発断・瞬断ゴトキでバンドメンバ上書き時のデータロス確率を>>388みたいに0に出来ないなら正直使えないしバレたらロック事件並みの騒ぎになるでしょう。まあそんな仕様にする訳ないですが。
ちなみに388が書かれた時はMC操作手順によるデータロスト確率0を前提としてます。その上で書き込み不安定によるロスト確率を下げるにはベリファイしか浮かばねーよとして、ベリファイを含めた手順を整理してましたね。 >>392
適正(適するように正す)ではなく適性(適した性質)な
重箱の隅ではあるけど >>400
それはわかるんだけど、あまりにパフォーマンスが犠牲になるので……。
ヘッド退避はできてるわけだし、バンドひとつ分の書き込みくらい
コンデンサ容量アップでなんとかならないかな。
まあ、ベリファイしてまで信頼性を上げようという話なんだしリスク回避最優先なのは当然か。
考え足らずでした。ごめんなさい。
実際のところ WD 方式のアルゴリズムばかり考えているところに
たまたま貼られたのでついでレベルに言ってみただけでろくに考察しなかった……ｗ
で、昨日は文がまとまらずやめちゃったんだけど、>>395 にレスすると
ガベージコレクションで速度が回復するのは効果の一面に過ぎず、
本質的にはやらないと総 LBA 分の容量が確保できなくなってしまう。
激遅状態は、仕方なくその都度ガベージコレクションしながら書き込んでいるみたいな感じ。
あと、トリムのその説明もブロック単位で割り当てるときのことしか触れられておらず
ブロック内の全てのページが未使用になったときにしか効果がないように思えるが、
ページ単位で割り当てる場合にはディスク全体における未使用ページの総数が
直接響いてくるのでもっと重要。消去の仕様にもからんでくるものの、
本質は空きブロックの確保なので WD の SMR にもあてはまる。 >>410
別にWD方式でガベコレしなかったとして LBA 分の容量が確保できなくはならんと思うけど
物理＝論理アドでスタートして
未使用バンドの論理アドへの書き込む場合はそのまま未使用バンドの物理アドが使用中になる
使用中バンドの論理アドへ書き込む場合は新たに未使用バンドの物理アドが使用中になって
今使ってた使用中バンドの物理アドが未使用になる
ってなるだろうから使用中バンドが不用意に増えたりはしないと思うが >>410
ああ、トリムはやらないと LBA 分確保できなくなると思うよ
ただガベコレは別に要らないと思う >>411
茂見たいに瓦バンド単位で管理してればね
その代わり、バンド内の一部データを書き換えるためには、その場でユーザー待たせてバンド書き換えやらないといけない
WDならドライブの空き容量が有るうちは、新たなバンドに書くだけで良い
ただ使い込まれると失効データで埋まった穴あきバンドだらけになるでしょ？
最終的に辻褄合わせしないといけないから、穴空きバンド集めて書き直す作業(つまりガベコレ)が必要 >>413
いや「新たなバンドに書くだけで良い」
って気軽に言うけどバンドって約30MBって言われてて
つまりosからの4KBのデータの書き込み要求でも最低30MB書かなくてはならないって事だから
CMRと比べたら既に致命的な遅さになるんだよ？ >>414
茂とWDのガベージコレクションの違いについてのレスだよ
4kBのデータはMCに書けば良いだけ
話が飛躍しすぎ >>415
うーん、何故そこまでわかっててWDはバント単位で管理してないと思えるんだ？
結局瓦ではバンド単位でしか書き込み、書き換え出来ないのであれば
バンドより小さい単位でアドレス管理しても無意味じゃね？ >>415
ああ、 >>395 のリンク読み直してなんとなくわかった
やっぱりSSDとSMRは大きく違うからSMRのWD方式にガベコレはいらないんだ
ガベコレについてSMRの瓦の30MBのバンドに当たるのはSSDの512KBのブロックになるわけで
SSDの場合512KB書くのがクソ早いかつMCも無いから4KBの新規書き込み要求があった場合
物理アドレスの近くに他のデータがあろうとマージなんてせずに新規ブロックに書き込む選択になる
だから後でガベコレという名のマージが必要になる
一方でSMRは30MB書くのがクソ遅い
だから4KBの書き込み要求があった場合ユーザーを待たせない為にまずMCに書く必要がある
で、後で30MBの瓦のバンドに書くことになるが
この段階で書き込み先のバンド内に他のデータがあった場合に
マージをしないで新規バンドに書くのであればさらに後でガベコレが必要になるが
もう既にユーザーを待たせない状況であるのにさらにマージを後回しにする意味があまりない
だからここでマージをする、なのでSMRではガベコレは要らないんだと思う
じゃあ何でわざわざ物理≠論理アドなんてするんだって理由は >>388 になる >>406
DRAMキャッシュ内のデータが電源断で飛ぶって事に関してはCMRでもSMRでもリスク同じでしょう。
DRAMキャッシュ容量分のリスクがある。
どう運用しようがね。
CMRだってNCQ待ちのデータ溜まるんだし、特段SMRがハイリスクだとは思えないな。
SMRはDRAMキャッシュ多い傾向にあるという話なら別だけど。
直接書きしてるとも、してないとも、どちらも明確な答えになる情報がない以上は結論でないけど、
直接書きしてないとは思えないパフォーマンスだと思うけどね。 >>418
DRAMキャッシュ内のデータが電源断で飛ぶ事が問題なのではなくて
瓦書きでは書き込み先のトラックに隣接するトラックのデータが破壊されるから
瓦書きでデータを上書きする場合はその直前に破壊されるデータをDRAMではない
不揮発領域にバックアップしておく必要があるってこと
>>409 の図を見てみてほしいが track1 と track2 が重なってるから
track1 を上書きしたら track2 も一緒に上書きされるんだよ
当然こんな事は CMR では起きない SMR 特段のリスクだから
CMR では必要の無い対応をする必要がある
その対応も考慮してあるのが >>388
いや >>388 の 312 は俺が考えたわけじゃないけど本当によく考えられてるよ >>417
＞もう既にユーザーを待たせない状況であるのにさらにマージを後回しにする意味があまりない
いや、SMR で問題になるのはユーザーからの書き込みが途切れなく続く場合。
メディアキャッシュが一杯になる段階では吐き出す速度が直接響いてくるんだから
少しでも速いほうがいいでしょ。
名無しがいくら言っても聞き入れないタイプの人みたいなので作戦を変えようｗ
>>1 の Microsemi の文書の２ページ目を読んでみて。
＞じゃあ何でわざわざ物理≠論理アドなんてするんだって理由は >>388 になる
あなたが今更それを理由として持ち出すのアレじゃない？ｗ
まあ、それはいいとして、不正終了時の耐性も考慮すると
次の三つの方式にはそれぞれメリットとデメリットがありどれが一番かは決めがたい。
１．アドレス変換なし
２．バンド単位のアドレス変換
３．セクタ単位のアドレス変換
で、話は >>367 に戻るんだけど、Trim の有用性は下にいくほど高まるとはいえ
１でもまったく無意味ではないので、Trim があるからアドレス変換しているとは限らない。
つまりどれだか確定できない。
シーゲートが２の可能性だってある。Trim なしで３はまあないとは思うが、
Trim が使えない頃からプチフリ問題を抱えながらも SSD は存在していたわけで
絶対にないとは言い切れない。
アドレス変換をしている場合、代替領域を明確に区別する必要がないので、
その分余剰があることになりなんとかなるかも？ >>419
自分は電源断直前に書き込まれたデータが失われることと
過去に正しく記録されていたデータが失われるリスクの違いは理解してるが、
そういや 512e のリードモディファイライトも同様だね。
まあ、１セクタと１バンドじゃぜんぜん違うけど。 >>419
だから上書きされる予定のデータなんだから飛んでも問題ないといっている
SMRの仕組みは理解してるよ。
3段構成の場合2段目を書いたら3段目が破壊されることもわかってる。
だから既存の2段目3段目が不要となる場合に直接書けば良いといっている。 破壊される場所がわかっているんだから、
そこが不要となる場合に直接書きに行けば良いと言ってる。
バンド全体の更新データがDRAMにあるのなら既存データの破壊なんで無視して書きに行けば良いんだし、
バンド途中トラックからのデータを書くにしても、そのトラック以降のデータがDRAM内にあるときに直接書きにいけばいい。
上書きされて不要となるデータをわざわざメディアキャッシュに退避する必要あるの？
もちろんバンド内の一部のデータを書き換えたい場合は
メディアキャッシュにイメージ作ってからバンドに書きにいくことを否定はしないよ
>>423
HDDが電源断したらHDDのDRAMのデータは吹っ飛ぶでしょ
そして電源断によって破壊される可能性があるのはOSが書き込み要求したデータだけでなく
書き換え先のバンド全域、SMRはバンドを丸ごと書き換えるわけなので
だから復旧用に書き換え先のバンド丸ごとMCにバックアップしておく必要がある >>424
アドレス変換しないならそうなる
WD方式は書き換えるデータを新規バンドに書く、書き終えたら前のバンドを無効化するだけ >>425
そうだよ。WD方式は瓦書きでバンドの書き換えをしないから MC に既存のバンドのバックアップは不要だよ
だから >>388 でも WD 方式にはバックアップ処理が書いてない
というか WD 方式の利点はそれ >>420
> >>1 の Microsemi の文書の２ページ目を読んでみて。
たしかにガベコレやるって書いてあるな！でもなんか書いてある事が怪しいというか
「バンドの終端に新たなデータを追加できるようにする必要があります」って何のため？
消去された位置がわかってるならそこに新たなデータは追加すれば良くない？
この理由がわからないとこの文書の言ってるガベコレの挙動が定まらないと思うけど >>424
バンド全域の書き換え指示がDRAM内にあるのに既存バンドからデータを退避するのか？
何のために？ >>428,423の主張が何なのか解らないので具体的に書いてみる。瓦バンドが3層で
・層1にデータa
・層2にデータb
・層3にデータc
が有り、データaをAに書き換える要求が来たとします。OSはa→Aの書き換えダケのつもりだけど、瓦HDD内では…
abcをメモリに吸い上げ(バンド全域の書き換え指示がDRAM内にある状態)、層1にAを書いた時点で層2,3のbcは破壊されています。
この時点で電源断が来たらbcは救えないので>>388のような処理をしていると私は認識していますが、>>428,423さんの処理はどうやってbcがロストしないと主張しているのでしょうか？ >>427
セクタ単位アドレス変換方式
（どのメーカーがどれなのかまたわからなくなってきたので言い方を変える）では、
必ずしも瓦に一気書きする必要はないんだよ。
メディアキャッシュメインで設計するなら分割書き込みするメリットあまりなさそうだけど、
同時録画なんかの場合にそれぞれを別の空き瓦に直接随時追加するってのはありかも。 不正電源断問題については、
それぞれで前提の違う人同士が相手の前提を把握せずにレスしてカオスになってるなｗ
件の人はなぜか瓦直書きに特化した話をしてるみたいだけど、
みんな書き換え前提なんだよ。言い出しっぺの自分が言うんだから間違いない。
で、いちいちメディアキャッシュに戻すのはパフォーマンス的にやはり有り得ないと思う。
電源断直後に振動が加わったら終わるのでコンデンサ作戦では不十分と考え直したが、
NAND にでも緊急退避すればいい。
設定保存用のそれに余裕があるなら流用すればコストもかからない。
もしくはシーゲートを含む全メーカーが少なくともバンド単位での変換はしていて
そもそも最初から問題がない。
DRAMキャッシュ内にバンド内の一部のデータしかないのなら直接なんて書けないからメディアキャッシュに行くし、
DRAMキャッシュ内にバンドデータ一式が揃っているのなら直接書けるというだけの話でしょ。
>>431
逆にMCにバックアップすれば済むものをわざわざCMRには不要だった
NANDを積む価格コストを増やすものかとも思うが
それにパフォーマンスって言うけどそれやっても4KB書くのに30MBの読み書きはしないといけないわけで
100MB/Sとして0.6s＋α、MCにバックアップする場合は1.2s＋α
どうせ0にはならないバックグラウンド処理を早くするのにそんなにコストを払う物かな
因みにあるSMRではMCは23GB積んでるらしいが >>429
DRAMキャッシュ内にディスク上abc用のあらたなデータABCが来た場合の話をしているんでしょう。
a用のAしか来てないのならそりゃ退避は必要だとろうさ。 >>432
DRAM内と瓦にバンドデータ一式、MC内にバンドデータの一部の書き換え対象のデータしかない状態で
瓦のバンドデータを書き換え中に電源断が発生すると
瓦のバンドデータ内でMC上の書き換え対象データでは無い場所も破壊されるから復旧不能になるって話 >>348
遅レスだけど「後で見るため」
数日で消されちゃうページがよくあるので >>437
ページ数で年間数千から万ページ
１ページで数十ファイルからへたすると百個超えるものも
（MHTMLが滅んじゃったから単一ファイルで保存出来ない）
ほとんど見直すことがないんだけど保険の意味で残している…
バックアップの所要時間想像して壊れたら壊れたで諦めることにしている >>434
やっばそう言ってたのか。でも一部書き換えに一般化して話してる人(>>429前提で話してる人)が多いんじゃないなか？
なぜなら、全書き換え＝30M分貯まるまでメモリに保持する場合、貯まって書くまでOSに書き込み完了を送れない
かつ
まったく関係ないファイルが30Mに含まれる＝何時までたっても貯まらない可能性だって結構あるから(やれん事も無いだろうけどメインルートでは無いと思われる)。
で、>>388の整理はwd方式もseagate方式もどんな書き換えでも手順上の問題でロストしないようにしてるってだけ。
>>439 ありがと。言われてみたらその方が良いわなw 新規のファイル群や大きなファイルの書き込みなんかでは30M程度の連続データなんて頻繁に発生するんじゃない？
そんな時に直接書きに行ければいいやくらいな話じゃないのかな。
バンドの開始セクタがホストから伺い知れないことを考えると、
60Mくらいのデータの連続セクタ書き込み指示が有ればバンド一つ分くらいは直接書きに行けるみたいな。
データストリームが一つなら比較的に容易に実現できるんじゃないかと。
>>440
DRAMに全てあるのならという条件付けて話しているのに一部書き換えの話で反論されても困る
>>442
全てがそのシーケンスで処理してるとは思えない >>443
例えば瓦にa.txtとb.txtのデータがあったとしてa.txtだけを書き換えると
b.txtも消える事があるのよ
というかa.txtだけを書き換えるって事が出来ないのよ
だからMCにa.txtがあってDRAMにバンドデータが丸ごとある状態で瓦のバンド全体書き換えようとして
a.txt書き換え中に電源断すると
a.txtはMCにあるから大丈夫でも全然関係ない瓦のb.txtが消えるから
元の瓦には復旧出来なくなるのよ >>430
てか、書いてあった。
＞書き込み中のランダム性を許容するため、
＞または複数のビデオストリームの記録や同時バックアップ実行のような、
＞複数の連続ストリームからのデータを保存するため、各SMRドライブは、
＞データを各バンドに追加することを可能にする書き込みポインタを有する複数のバンド
＞（「ゾーン」と呼ばれる場合もある）を有しています。
とりあえずこの文書においては、
セクタ単位アドレス変換は当たり前みたいな話になってるなあ。 >>433
「4KB書くのに30MBの読み書きはしないといけない」からこそ
少しでも効率よくしないとまずいんでしょ。
それはワーストで実際にはもっとまとめて処理できる場合もあるが、
シーケンシャルアクセスは直書きされることを考えると
メディアキャッシュ行きになったものを吐き出すためには
かなりの作業量が必要になると推定される。
メディアキャッシュが溢れたあとのことなど知らんという考えなら
この話題に参加する必要はないと思うよ。
なるべくそうならないようにするにはどう処理するべきかという話なんだから。
>>439
書き換えセクタはひとつとは限らないので単純に半分にはならないけどね。
でも、そういや途中から書ける件を考慮するの忘れてたなあ。
NAND 等で対策した上で直接書き換えするアドレス変換なし方式がますます有利に。 >>440
＞なぜなら、全書き換え＝30M分貯まるまでメモリに保持する場合、貯まって書くまでOSに書き込み完了を送れない
そんなことはないよ。
ライトキャッシュ有効な CMR だって RAM に入り次第すぐに書き込み完了したことにしてる。
まあ、長時間 RAM に放置するわけにもいかないので
直書きするのはコピーみたいな高速転送時のみで、
録画なんかはたとえ連続 LBA でもメディアキャッシュ行きだろうね。
……あ、これも緊急時 NAND 退避作戦使えば解決できるな。
色々有用じゃないかｗ 瓦なんてコストダウンしか目的が無いものにNANDなんて積むわけないじゃん
>>447
効率化するに越したことは無いがそこを速くして誰が救えるかもちゃんと考えといてはくれよな
救えるのは数MBのファイルを数万ファイル一気に追加書き込みする猛者だけだからな
5万ファイルはいけるようになったけど10万ファイルは駄目だったーとか
そんな極一部のマニアな人の為に一般人がNAND代を払う事になるとか勘弁してほしいと思うし
メーカーがそんな選択をするとは思えないけどな >>443
「DRAMに全てある」を
・あなたはOSからの新規要求
・私はOS→MCと瓦から読み込んだモノ両方
を前提としてたから話が合わなかったと認識してますが違いますか？
私は元々の話…>>388の
>(0.MC読み)
>1.瓦読み
>2.マージして新MCに書く
からMC/瓦から読んだモノを前提に話してましたが、あなたは何から30M全てOSからの新規要求を前提にしたのですか？(388関係なく新しく新規要求の話をしてたなら理解は出来ますが、そーですかって感じ)
まぁ言われている意味が判ってスッキリしたので私はもうこの辺で良いですが。
>>444
その場合は388をやらんとダメって認めてるようですよ。彼は30M全部新規要求に限って話してる。 規制にかかった…
>>448
キャパシタか何か+緊急用NANDは有用とは思いますね。ただ…部品増による故障箇所増と何よりお金(部品代、試験コスト等々)が問題かとw >>451
あ～、瓦に直書きの話か
だったら確かにMCにバックアップしなくても大丈夫だな
これは失礼した >>452
緊急用NAND常用しちゃったら緊急時に使えなくなるんじゃね？ >>443
MC使わずに瓦に直接書く話であればバンド丸ごとである必要は無く
バンドの終端アドレスを含むシーケンシャルライトであれば瓦に直接書けると思うけど
例え1MBでも
丁度 >>439 で海門方式の詳細なんてのも発掘されたのでこれ見たら
理解してもらえるんじゃないかなと >>450
なんでそんな極端な考えになるかな。
SMR の速度低下に不満を感じるすべての人に関係することだよ？
今不満がなくとも断片化が進めばどんどん厳しくなるのでいずれ表面化する可能性もある。
Archive HDD として売っていた頃ならともかく、
今は区別できなくしてるんだからなるべく普通に使えるようにしなくては。
まあ、こっそり入れ替えて値段も下げず、コストダウンで生じるメリットを
ユーザーに還元することもなくボロ儲けしようとしているようなメーカーが
追加コストを出したがらないだろうということには同意しておく。
でも、技術者は頑張ってるはずだ。守銭奴の都合などこのスレで考慮することはない。 >>449
>>452
何も GB スケールの本格的なものを積もうってわけじゃない。
今の HDD はプラッタの面ごとに密度が異なる等個体差があり、
それを吸収するためになんらかの不揮発性メモリがあるので
（そのため基板交換すると動かなくなる）それを流用できるかもしれない。
容量が足りず増量することになったとしても、
ないところに追加するよりはコストもかからないでしょう。
CMR だってキャッシュ容量を増やしてきたんだし、
性能アップのためにコストをかけることがないわけでもない。
決して非現実的というわけでもないと思う。
>>454
なぜ常用すると思ったの？ 不正電源断問題については >>431 で言及したんだけど
わかってくれた人があまりいなかったようで残念。
各自の言い分を注意深く観察してたけど、
>>401 さんがなぜか瓦直書きの話と取り違えたんだ思うなあ。
>>397 が自分だけど単体でも明らかに書き換えの話だとわかるよね？
それへのレスである >>400 の直後だし……。
今現在、WD 方式という言葉を
バンド単位アドレス変換とセクタ単位変換の両方で使ってる人がいるので要注意。 >>457
断片化が進むと何が厳しくなるんだ？
瓦がいくら断片化しようとSMRではとりあえず断片化してないMCに書くわけだからむしろCMRより有利では？ >>458
>>なぜ常用すると思ったの？
緊急時の為のバックアップを常用的に取っておく為に使うのかと思ったから >>460
断片化が進めば、シーケンシャルライトでも直書きできず
メディアキャッシュ行きになる割合が増えるので、死がそれだけ近付くってこと。
昨日も言ったけど、メディアキャッシュがあるから大丈夫ではなく、
その先の、溢れさせないため（延命させるため）には
吐き出しの効率を高めることが重要という話をしてるんだよ。
恐らく書き込みが続いても溢れないよう裏で吐き出し続けてる WD の場合も、
その処理の分書き込み速度が遅くなるので効率はやはり重要。 >>461
電源断を検知してから退避するんだよ。
コンデンサ（キャパシタ）によって電力供給が途絶えても短時間なら動作できる。
ヘッド退避できるくらいなので不揮発性メモリに書くくらい余裕。
それこそコストを度外視していいなら、
本格的な RAID のようにバッテリーバックアップされた RAM を常用すればいいけどね。 >>462
死ってMCが溢れるって事？
いやMCって20GB位あるらしいけど逆にどうやったら溢れるか考えてみって
1MBのファイルだったら2万個以上書き込む必要があるんだよ
断片化で溢れさせるなら30GBの動画ファイル書き込んだら断片化が酷くて2万箇所に分断されたぜ
っていうようなギャグみたいな奇跡が起きないと厳しい
少なくとも100や200じゃ溢れようがないわけでな >>464
「シーケンシャルライトでも直書きできず」と言ってるんだから、最悪で言うと4kセクタでもディスク総容量(例8T)÷30M÷4k書いたら直書きできる瓦が無くなる＝劇遅モードに入る可能性が激増すらからガーベージで空きを作るベキと言ってるんだと思う。
それはそーですよね。
ガーベージもコストかかるからチューニングの腕の見せ所てますが、仕様をろくに見せない(どころか何れが瓦か分かりにくくしてる)現状ではなんとも(泣 可能性が激増（ファイルの断片化が連続で1万回発生すると起きるようになる）
いやほんとMCって20GBとか積んでるんだよ！
ひっきりなしに書き込みしてたまたま断片化して細かくなったファイルだけ集めて20GBとか
普通に使っててなるわけないじゃない！
瓦用のユーティリティ出して、書き換え頻度の高い小ファイルは常時MCとか
設定できるようにしておけば大分効率上がると思うけどなあ
仕様知られるのは嫌なのか海門そういうのはやらんのよね
>>463
ヘッド退避はコンデンサじゃなくてモーターの起電力でやってるから、
完全に電圧とか制御されてなくて通常退避の数十倍の機械的ダメージあるんだけど >>464
なんだ。それなりに技術話もできるようなので付き合ってたが、
「SMR にはなんの問題もない。遅くなるような使い方をする奴が悪い」一派か。
それなら Archive HDD のままでいいんじゃないですかねえ。
断片化を甘く考えないほうがいい。
ファイルを作っては削除を繰り返していると空き領域には相当数の断片ができる。
ファイルコピー等サイズがわかっている場合にはうまく確保するのでそんなでもないが、
細かく書き出すタイプの処理ではシーケンシャル出力でも簡単に千単位の断片化が発生する。
通常エンコ作業は専用に切った小さいパーティションでやってるが、
空き容量が足りず使い込んだ録画用パーティションを流用したら酷い目にあった。
まあ、CMR なので事前処理の部分が十倍くらい遅くなるだけで済んだが。
気付いてからは contig で回避してる。抜本的解決としては空き領域のデフラグ。
長時間番組になれば単体で 20GB とかざらにある。
ＣＭカット作業等の出力が千に分かれたら各断片の平均が 20MB だから
大半がメディアキャッシュ行きになってそれだけで枯渇するかもしれない。
同一 HDD で録画しながらエンコ作業を日常としている人は普通にいるだろう。
>>448 に書いた理由により録画は恐らく瓦直書きにはならない。
それほど断片化が進んでいなくても厳しい状況になる可能性は十分にある。
そこに何か別件でファイルコピーなどしようものなら……。 >>472
仮に20MBがMCに乗ったところで瓦書き速度は2MBがMCに乗ったときの10倍になる事は把握出来てる？ >>471
プラッタ着地時代はともかく、今は高度なプラッタ外脱出なので
退避完了まで CPU も生きてる必要があると思ってたけど、
高度なのはヘッドを乗せるときで、退避時は勝手に固定される機構でも不思議じゃないか。
ダメージについては保証回数に一桁差を付けるくらい違うことは知ってるけど、
HGST の SMART の C0 と C1 が同値なあたり、
「今はそれほど気にしなくていい」というメッセージだと勝手に思ってるｗ
コンデンサの話に戻ると、瞬断対策としても入ってるんじゃないかと。
うちの安物電気ポットでもコンセントが抜けたあとに「ピピッ！」と鳴く程度の余力はあるしね。 >>472
仮に20GBのファイルが断片化で千個に爆発四散するとして
それCMRでもまともに動かんでしょ
その状態で録画と編集を続ける？容量もカツカツなのに？
SMRでもデフラグ出来るようにしろっていうなら真っ当な要望だとは思うが
現状で現実的な時間で出来てるのかどうかは知らないが >>472
あと20GBのファイルが千個に爆発四散するようだったらどんなにMCを上手く活用したところで焼け石に水でしょ
瓦書き<<<通常書きは覆らないんだから
MC溢れて止まるのは防げず編集なんて出来るようにはならない
デフラグかファイルの移動して容量を空けるしかないんじゃないかな しょうが無いじゃん。SMRには何の問題が無いと１万回書き込むと世間を納得させられると信じてるんだよ。
そういう仕事を請け負っているから、良心が痛むことないし、どんな障害が発生しようと他人事だからね。
>>472
大事な事を言い忘れてた
その件をメーカーが対応するならMCのサイズを増やせば良い
だからそういう苦情が多くなればMCのサイズは50GB100GBと増えてくだろうね
現状はそんなん発生しないだろうと踏んで20GB程度なんでしょう >>473
「ギャグみたいな奇跡が起きないと」溢れないという主張に対し
普通に起こり得る例として挙げてみただけで、その先は知らんよ。
理論的には吐き出し処理もそう厳しくなさそうだが、
現実には断片化してない状態で３～４個同時コピーした程度で >>302 の有様。
おしなべて一度酷い状態になるとどうにもならないみたいなので
一杯になってから慌てて吐き出そうとしてもうまくいかない何かがあるんじゃないの。 >>475
いや、事前処理（音声切り出しとか）が遅くなるだけで
エンコのメイン処理に入ればゆっくりリードなので千個適度どうということもない。
事前処理にしても、自分はシーク時間が大きく影響することを知っているので
専用パーティションを使ったりしているわけで、
ぜんぜん気にしない（気付いていない）人も多いんじゃないかな。
容量カツカツってこともないよ。100GB 程度しか空けないこともあるので
余裕のある運用には程遠いけど、とくに困らない。
いくら空けようと新規録画は連続クラスタ（なくてもなるべく断片化してないところ）に
確保されるので細かい空き領域は増える一方。
爆発四散とか、なんか勘違いしてるみたいだけど、
ワークとして使ってればふつーに起こり得ること。
CMR なら大した問題ではないが、
SMR では致命的な事態になる可能性がある例として挙げただけ。 結局、ファイル作成と削除を繰り返すような用途において SMR は信用できない。
今日行えた作業が明日も滞りなく行えるとは限らない。
嘘だとわかっていながら「CMR 同様に使えます」と言って売らなくちゃならないんだから、
なるべく発覚しないように効率を上げねばならない。
どうしたらええんかね（どうやってるんかね）……という話をずっとしているつもり。
正直に優る策なし
せめてSMRの明記はしろ、リスク開示とセットで
WDが鯖用途前提のREDシリーズで
SMRをラインナップしたのはどういうことなのか
分析したほうが有益なのではないかな？
>>478
特に議論不要ですが一寸だけ。
「増やせば良いだけ」ってのは違うかと。
単純に増やすと発生リスクは下がるが、発生時の被害が大きくなる。
→仕様によって適正サイズがありチューニングの腕の見せ所。
JVMのメモリ系パラメータも一緒ですね。 >>484
発生時の被害って何？
多分勘違いしてると思うけどMCって10GB空いてれば10GB、20GBなら20GB、50なら50書けるだけだよ
50GB埋まっても全部空にならなくても20GB瓦書きして空けば20GBまた書ける
多くても瓦領域が減る以外に特にデメリットは無いと思うけど 後俺は別にSMRに問題が無いと言いたいわけではなく
MCから瓦への書き出し処理は >>388 で十分でしょって言いたいだけ
これから何かを犠牲にして速くしてもそんなに良い事は無いと
何も犠牲にせず速く出来る方法があればやるべきか既にやってると思うけど >>485
MC枯渇後に発生すると考えられる超低速モードの継続時間 DIGAにSMRのHDD採用されてるな
DMR-UBZ2060にST2000VM005が入っていた
20mmハイトの薄型だったから2TB1枚と思われる
ST2000VM005ならAV用の2プラッタかと思うんだが
トラックピッチも352ktracks/inでSMRの数字じゃない。
>>487
超低速モードとはなんぞ？ってところだけど
MCが溢れたら何故異常に遅くなるか
MCが1KBの隙間も無く埋まったとする
そこにOSからSMRに100KBの書き込み依頼が来る
当然MCに空きがなく書けないのでSMRからOSに書き込み完了通知が返せない
これが異常に遅くなる原因
そしてOSからの依頼とは別に行っている
MCから瓦領域への瓦書きによってMCに空きが100KB空いた時に
OSからの100KBの書き込み依頼がMCに書けるのでここでSMRはOSに書き込み完了通知が返せる
さらにOSから100KB書き込み依頼をすると同じように待たされるの繰り返し
MCの容量は関係ないでしょ？ >>491
と、言うような処理が溜め込んだMCダケ続ける。無論何処まで吐いたら書き込みを優先するとかもありサイズに「直線比例」では無いけど、それら含めて「チューニング」と書いたんですよ。常駐Javaのメモリチューニング地獄と同じ系統の問題ね。
まぁ深く考えた書き込みじゃないんでこの辺で許してw >>488
コストに厳しい家電はどうせ使うだろうと思ってたが、やっぱりか。
まあ、レコは同時３番組録画までなのでぜんぜん大丈夫だろうけど。
クラスタサイズ大きくしとけば断片化の心配もない。
てか、レコなんかこそホストマネージドが最適だよね。１クラスタ＝１バンドでいい。
まあ、わざわざ研究開発費かけてやらないだろうけど。
そもそも、HGST が作ってた形跡はあるものの、
サンプル出荷を超えて量産されたことがあるのかすら怪しいしｗ >>492
お、おう？
まあチューニングでわざわざ超低速にしたらいかんでしょ
チューニングっても基本ユーザーの使用頻度に反比例して瓦書きする位だと思うけど
それだけでもどうせMC枯渇したらユーザーの使用も止まって瓦書き優先になるし >>493
家電はHDDの用途が限定されるからSMRで全機能問題なく動作するなら
むしろCMRを使う意味が無いからな
録画は遅くてもシーケンシャルライトだから
MCに乗ってもなかなか問題は出ないだろうね >>492
あー！「溜め込んだMCダケ続ける」ってのがおかしい！
溜め込んだ量はまったく関係ないよ
だってMCが1GB空いたらOSからの書き込み要求を1GB書けるわけだから
溜め込んだ量が19GBでも49GBでも関係ないでしょ？
だからここで関係するのはMCの空きと瓦書き速度とOSからの書き込み依頼の量であって
MCに溜め込んだ量はまったく関係無い >>492
だからいつまで続くかってのは
OSからの書き込み依頼が瓦書きの速度を上回る限り続く、MCの空き容量が確保できないので
ってところかな 市販レコにSMRか。
AVコマンド対応ドライブってのもあるけど、
ドライブ内のSMR処理に優しいコマンド発行をホスト側がすれば使えるんかね。
他のSMRドライブに換装しても当初性能を維持できるのかが気になる。
汎用録画向けドライブであるSkyhawkではまだSMR出てきてないようだし、
OEMならではってことかね。
>>500
コマンドを気にするというか例えばOS側で100MBづつ揮発メモリにキャッシュしてから
SMRに書き込みしてれば殆どMCには乗らないから問題なく使えるんじゃないかな まあ録画をOSでキャッシュしてなくてMCに乗っても3チャンネル同時録画位だったら
瓦書きで間に合いそうな気もするけど
今になって思えばなんでCMR時代に録画用HDDの選定的なモノがあったんだろ
1チャンネル2MB/s位なんだろ？書けないわけないでしょっていう
メーカーに乗せられてた？
>>503
何言ってんの？必要も無いのに録画用って仕様が出来るわけないのに。
このスレ的にSMRが監視カメラ用も含んで録画用に向かないか考察してみろって。 監視カメラ用ドライブは多並列なデータストリームへの最適化と
AVコマンドと呼ばれるリアルタイム性重視の映像ストリーム用ATAコマンドの対応が売り。
並列性を手加減したうえでホスト側がデータ粒度を大きく取るなどの対応をすれば、
ストリーミング記録はSMRに向いてると言えなくもないね。
SMR処理が間に合う範囲であるのならだけど、映像ストリームは予測しやすいデータストリームであるし。
録画用途に絞るなら、クラスタサイズ20MBのファイルシステムにすれば全て解決
裏方で何だかんだ動かれるよりよっぽどマシじゃね？
>>505
AVコマンドってエラーを無視して書き込みを継続出来るコマンドってあったんだけど
通常の書き込みコマンドってエラー無視して継続出来ないものなの？ >>504
考察してみろって煽りながら自身はまったくしないってよくわからん無能っぷりだなww 過去書き込みリトライ率高くて時間かかる時代にはAVコマンド必要だった
今それほどでもないので採用が減ってる
保証期間中に壊れない程度のグレードにしてるが書き換えと可動時間多い全録はred使ってたりする
>>510
あー、つまり通常の書き込みコマンドはHDD内部で自動でリトライしてしまうから
それだと書き込み間に合わなくなって困るって事なのかな？
じゃあキャッシュ積めよって気もするがw
で、実際キャッシュも多く積まれるようになってそもそもエラーも減った
今となっては何の為にあるのかわからんコマンドになったと >>206
CMR(WD青)、SMR(WD青/SG バラクーダ)の比較検証の最終結果です。
XQDのデータ(121G)を書き込むのにかかった時間を測定しています。
OS
Win10 pro 64bit
コピー方法
エクスプローラの標準コピー
所要時間を測定
対象HDD
WD60EZRZ(CMR)
WD60EZAZ(SMR)
ST6000DM003(SMR)
いずれも同一の外付けHDDケース(USB3.0)に入れた状態での測定です。
コピー元
XQD
121GB
1ファイル19MB程度
約6500コ
カードリーダ SONY MRW-E90(XQD) >>512
WD60EZRZ(CMR)
[1] Format直後 14m45sec
[2] 1.3TB程度使用時 15m52sec
[3] 2.4TB程度使用時 14m30sec / 最測定 15m35sec
[4] 3.7TB程度使用時 17m21sec
[5] 5.0TB程度使用時(残473.2GB) 22m24sec
[6] 5.1TB程度使用時(残351.4GB) 23m17sec
[7] 5.2TB程度使用時(残229.6GB) 24m12sec
[8] ディスク容量限界まで書き込んだあと適当にあちこちのファイルを削除して空き容量を確保した上でのデータ転送 13m58sec >>512
WD60EZAZ(SMR)
[1] Format直後 11m27sec
[2] 1.3TB程度使用時 12m39sec
[3] 2.4TB程度使用時 13m59sec
[4] 3.7TB程度使用時 16m46sec
[5] 5.0TB程度使用時(残473.2GB) 23m21sec
[6] 5.1TB程度使用時(残351.4GB) 24m22sec
[7] 5.2TB程度使用時(残229.6GB) 25m41sec
[8] ディスク容量限界まで書き込んだあと適当にあちこちのファイルを削除して空き容量を確保した上でのデータ転送 12m42sec >>512
ST6000DM003(SMR)
[1] Format直後 18m13sec
[2] 1.3TB程度使用時 19m57sec
[3] 2.4TB程度使用時 21m29sec
[4] 3.7TB程度使用時 24m19sec
[5] 5.0TB程度使用時(残473.2GB) 30m38sec
[6] 5.1TB程度使用時(残351.4GB) 31m21sec
[7] 5.2TB程度使用時(残229.6GB) 32m30sec
[8] ディスク容量限界まで書き込んだあと適当にあちこちのファイルを削除して空き容量を確保した上でのデータ転送 20m05sec なかなかMC溢れた感じの挙動にならないね
1ファイル19MBが大き過ぎるのかな？
>>512
いずれの場合も、途中で書き込み速度が極端に遅くなるような現象(いわゆるMC溢れ)はありませんでした。
ただひたすらデータを書き足していくだけの使用方法でなおかつファイルサイズが19MB程度だと、MC溢れ
は起きないということですかね。
書き込み速度の比較では、使用量が5TB以下ではWD60EZAZ(SMR)の方がWD60EZRZ(CMR)よりも速かっ
たです。ただWD60EZRZ(CMR)の測定値には若干の疑義もあり、本来の実力はもうちょっと速いのではない
かと思ってます(実務での経験値も含めて)。そういう点も含めて、WD60EZRZ(CMR)とWD60EZAZ(SMR)は
実用上の差はほぼ無いと思います。
一方ST6000DM003(SMR)は、WD60EZRZ(CMR)とWD60EZAZ(SMR)に比べて明らかに書き込み速度が遅
いです。これがWDとSGのSMR方式の違いによるものなんでしょうか？ それとも基礎的な実力差が現われた
だけ？ あと気になったのは、ST6000DM003(SMR)は書き込み中の書き込み速度が大きくばらついていたこ
とですかね。
データ保存用途(ひたすら追記だけ)に限った書き込み速度という観点から評価した場合、WD60EZAZ(SMR)
はこれまでのWD60EZRZ(CMR)とほぼ同じパフォーマンスが期待できます。一方ST6000DM003(SMR)はWD
に比べるとややパフォーマンスは落ちるけど、想定していたほどの差では無かったです。 >>515
海門のST6000DM003(SMR)がかなり遅いって事は
裏でかなりリソース割いてMCから瓦書きをしてるって事だろうね
にしてもWD60EZAZ(SMR)の異常な速さはなんだろな
WDはバンドを小さくして瓦への直書きをしやすくでもしたのかな？ >>516
[8] ディスク容量限界まで書き込んだあと...は、これならMC溢れが起きるのではないかと思ってやった
のですが、残念(？)ながら起きませんでした。 >>517
今回の検証で、少なくとも書き込み速度という観点では、SMR HDDはデータ保存用として使い物に
ならないのではないかという不安は払拭できました。ただデータの信頼性という点では、不安は残り
ますけどね。
あと頻繁にファイルの削除、書き込みが発生する作業用のHDDとしてSMR HDDの適性はどうなのか
というのはわかりません。こちらはなかなかテストでの検証もし辛いので、実際に使ってみて変な現象
が起きないか、気長に観測するしかないかな？ なんとなくこっちの使い方では、SMR HDDの悪い所
が露呈しそうな気がします。
SMRでも(書き込み速度という観点では)データ保存用に使えることがわかったので、今保有している
(買い溜めしてある)WD60EZRZ(CMR)は、データ保存用ではなく将来の作業用HDDとして温存してお
いた方が良いような気もします。 >>512
あと気になったのは、WD60EZAZ(SMR)とST6000DM003(SMR)について、同一HDD内でのデータの
コピーを行った際に発生したリンクダウン(OSがHDDを見失う状態)ですね。
これは使用量を増やした状態を作るために、すでにHDD内にあるデータ(1.21TB)をソースとして同じ
HDDにコピーをした時に、途中でOSからHDDが見えなくなって作業が中断したものです。WD60EZRZ(CMR)
ではこの現象は起きませんでした。
この掲示板でのアドバイスでは、高負荷時のHDDの応答時間がSMRだとCMRよりも遅くて、HDDケース
のSATA-USB変換チップが未接続状態と判断したのではないかとのことでした。
作業用のHDDであれば、同一HDD内でのデータのコピーというは頻繁に行う操作なので、そのたびに
リンクダウンが発生するようでは困ります。余力があれば、どのような条件で発生するのか、回避方法
が無いか検証してみます。 >>521
ありがとWD(SMR)予想以上に良い感じね。
こいつを破綻させるやり方を考えると面白いかもw >>522
高負荷時というかそれが正にMCが溢れた症状なんじゃないかと思うけど
>>515 ではOSからの要求をMCに書きつつMCから瓦書きをしてたから
動作は遅いがMCが溢れなかったわけで
MCから瓦書きする余裕が無くなる程高負荷状態で書き込みしたらそらMCは溢れるんじゃないかと
ただそうなるとWDが >>514 で裏で瓦書きしてる素振りが見えないのが気になるけど WDが瓦書きをしてるように見えない理由択
- 何らかの仕組みで殆どのデータを瓦に直書きした
- 何らかの仕組みでMCからの瓦書きをスムーズに行った
- MCが巨大で余裕があったので瓦書きしてなかった
- 何らかの仕組みでMCからの瓦書きがOSからの処理の妨げにならないようになってる
>>522
とりあえずはマザボのSATAに直結するしかないかも
そのうちSMR対応 と謳ったHDD外付けケースが出てくるかも SMR(HDD)といいQLC(SSD)といいほんまストレージ業界は地獄やで
一番はデータの書き換えでしょう。
BMPのデータが有って画像のピクセルサイズは変更せずに内容を書き換えて上書き保存。
QLCは下にHDDがあるからまだいいけど
SMRはストレージ界の落ちこぼれだから必死だよ
>522
2.5インチのSeagate SSHD2TB使ってるけど、
Wowsとかで20GBぐらいパッチ落ちてきて再パッケージ化で60GBぐらい読み書きすると、
途中から遅すぎてネットワーク接続を確認してください、って表示になって止まるから。
何度も再開ボタン押す羽目になるんだよな。
SSDで同じことやると途中で止まらないし数倍時間がかかったりしない。
遅くなってる時は0.5MB/sとかタスクマネージャに表示されてる。
あと、この状態の時に画像をペイントで開こうとすると100%「ファイルシステムのエラー」です。
というダイアログが表示されて開けないんだけど。
イメージビューアの方だと開くのは遅いけど問題なく開ける。
8TBのHDDだけSMRで出してそれ以下の容量はCMRで出すように変えればいいんじゃね？
倉庫用途に使うやつなんてどうせ8TBしか買わないだろ
たのむぜSeagateさんWDさん
茂・WD「片面不良のプラッタ2枚組み合わせて2TB(SMR)として売る錬金術なのに、手放すわけないじゃん」
「大容量は高値で売れるデータセンター向け製品に絞る予定だよ」
>>531
HDDの容量小さいとMCの容量も小さくて溢れ易くなってると予想 >>531
ってSMRじゃなくてSSHDかよ！w そんなん知らんわw >>536
SSD部分を使い切ったらSMRではある >>537
それさー、小容量(8GBとか)を書き換えまくるSSHDって載ってるフラッシュメモリー大丈夫なの？
壊れたらHDD認識されなくなったりしたりして... >>538
よく知らんけど直書き多めの制御はしてるんじゃないかね
SMRベースのSSHDって確かキャッシュRAMの一部を使って書き込み制御用のミドルウェア？を動作させてるとかいった記事がいつかあったような そもそもSSHDっていろんな意味で失敗作で将来性は無いんじゃないの？
>>538
壊れ方によってはそれもあり得ると思うし
SSDの書き込み回数超えて書けなくなった場合なら
劣化版SMRとして機能すると思うけど
SMRである以上はMC積んでないって事も無いだろうし >>540
失敗というか過渡期の産物でしか無かっただけでは 据え置きノートにそこそこ安くてそこそこ速くてそこそこ大容量のストレージを乗せる手段としては評価してる
2Tが1/3の値段だもの
>>519
「適当にあちこちのファイルを削除」というのが
手作業でちょっとやった程度ならほとんど影響ないよ。
実験したいなら一個おきに削除とかしないと。
ファイル名が連番なら末尾が偶数のだけ消すとかね。 >>522
前にも書いたけど、同一 HDD 内でのコピーは FastCopy のほうがいい。
読み書きを同時に行わなくなるので効率がいいし何より HDD にやさしい。
リンクダウンが完全に回避できるかはわからないが。 >>525
メディアキャッシュは巨大ではないと仮定。
WD60EZAZ はほぼプラッタ性能通りの速度が出てるので大半が直書きで確定。
ST6000DM003 もとくに内周で半分まで遅くはなってないので部分的には直書きしてるはず。
「1ファイル19MB程度」ということで
バンド途中でファイルが終わり管理情報のアクセスが入ることがそこそこあり、
ST6000DM003 は直書きを諦めるが、
WD60EZAZ は管理情報だけメディアキャッシュに送りデータ本体は直書き判定を継続する
みたいな感じじゃないかな。
ST6000DM003 も激遅にはなってないので裏での瓦書きもスムーズに行ってるでしょ。 >>539
本筋と関係ないけど、HDD のファームはどれもキャッシュ RAM の一部で動いてるんじゃね？
ROM は遅いので RAM に移してからってのもよくあるが、
HDD のメインファームはプラッタ上にあるらしいので、それしか考えられない。
今は役に立たなくなった SMART のキャッシュサイズ、
RAM 全体のサイズを返すものもあったが、
中途半端な値……恐らく純粋にキャッシュとして使えるサイズを返すものもあった。 >>542
まだ終わってないから、絶賛販売中だからね!?
>>547
任意のSMARTコマンドを発行するソフト知っていたら教えて >>546
あー、俺は ST6000DM003(SMR) は >>513 >>515 で比較して全体的にかなり遅いから
全体的に裏で瓦書きしてるものかと思ってたけど
ST6000DM003(SMR) ってそもそものスペックがポンコツなのか？ >>549
ST6000DM003(SMR)は全体的にOSからの書き込み処理に影響の大きく出る
スムーズではない瓦書きを行ってる事な >>546
バンドサイズが30MBで19MBのファイルだと瓦に直書きは
期待値で1/3の6MB位しか出来ないと思うんだけど
それ以上直書きできるロジックがあるのかな 詰めて書かないで、容量大体使い切るまでは場所離してバラバラに書いてるんじゃないの
>>547
あー、SMR一般の話として「これこれで制御が複雑、ファームがでかいからRAM多めに積んでる」とかそんな話だったかも
元記事見つからないんで何とも >>549-550
最外周が 200MB/s 最内周が 100MB/s として、全部直書きでそれぞれ 10m と 20m、
全部メディアキャッシュ経由で常にスムーズに吐き出したとして同 30m と 40m、
ぎりぎりまで吐き出さすコピー終了時に 20GB 分溜め込んでたとしても同 25m と 33m。
実際にはこれにシークタイムや管理情報のロスが加わるし、
全部メディアキャッシュ経由はちょっと考えづらいので、
条件が揃ったときだけ直書きしてそうってことね。 >>551
データ本体のクラスタは次のファイルに進んでも連続 LBA になる。
たまにディレクトリ等が伸びてクラスタが割り当てられるがそれも含めればほぼ全部連続。
管理情報アクセス（離れた LBA へのアクセス）を区別すれば残りは全部直書き可能。
ディレクトリは何度も更新されるがそれはメディアキャッシュ行きにして
瓦に書いたものは無効にすればいい。
ちなみに、クラスタサイズを 4KB より大きくした場合、
余ったセクタには恐らく書き込まないので連続 LBA にならないケースが出る。
断片化防止には大きくしたほうが良さそうだけど痛し痒し。 >>555
それもありうるとは思うけど
だとすると >>513 >>514 >>515 共に殆どシーケンシャルライトしかしてないけど
ST6000DM003(SMR) が圧倒的に遅いって事になるけど、こいつそんなにポンコツなの？
瓦書きが無いのであれば SMR も CMR も速度差は無いはずだけど ちょっとググってみたけど
WD60EZAZ と ST6000DM003 ってハードスペックはほぼ同じって事で良いんだよな？
>>559
どちらのCMRだって大差ないよ、気にするなら8TBのCMR買うべき あと不思議な事に >>514 と >>515 を比較すると
どこで比較しても海門の方が7分位遅いんだよな
7分間は一体何に使われてるんだろうか >>562
つまりこの7分は瓦領域の内周外周に依存しない時間なわけで >>562-563
だから、それがメディアキャッシュを経由してる分のロスなんじゃないかなと。
扱ってる LBA が外周だろうと内周だろうとメディアキャッシュの位置は変わらないんだから
ロスが同じくらいになるのは別に不思議じゃない。
内周のほうがシーク的に少し不利だが、
どうせ１瓦アクセスするのに 10～20 トラック程度連続アクセスするのでそんなに差はない。
ちなみに、メディアキャッシュが最外周で 200MB/s だとすると、
７分の差は 42GB 分に相当する。 >>565
だから、最初に
＞WD60EZAZ はほぼプラッタ性能通りの速度が出てるので大半が直書きで確定。
と言ったでしょ。
ヘッドは一組しかないんだからメディアキャッシュを経由したら
最外周でのアクセス時間の二倍分は確実に増える。
大半が直書き可能はことについては >>555 参照。 何をどうしようが書き込みが二段階だからそら遅くなるで
>>566
そうだとするとまず瓦直書き判定ロジック的に海門の方だけMCに乗る書き込みが多くなる
そして余計にMCに乗った分だけバックグラウンドで瓦書きが発生し
その瓦書きによってOSからの書き込みが妨害されて遅くなった時間が7分固定だったと
微妙なのが内周に直書きされるものが外周にあるMCに書かれると
MCに書かれたほうが速くなるけどまあ少量で無視できれば無くはないか >>567
WDはその理由で大半直書きだとすると今度は何故海門は直書き出来なかったのか
何故海門は7分固定で遅くなるのかという疑問が残るなと もしかしたらWDも海門も >>555 によって大半は瓦直書きだったが
海門だけバカ正直にMFTをMCから瓦書きし続けてたとか？
MFTだったら更新量はファイル個数にのみ依存なので
内周外周に関わらずロスが7分固定なのも辻褄は合うと思うけど それならexFATにすればほぼ解決するんではないだろうか
>>571
茂はバンド単位の制御で、WDはクラスタ単位のアドレス変換やってるっぽいんでしょ
WDだけtrim実装してるし
でも細かい事を気にするならCMR買えば済むんじゃね？ >>572
更新対象がMFTからディレクトリ情報になるだけじゃね？
俺のexFatの認識が間違えてる？ そろそろメディアキャッシュは本来SMRに不要だった。むしろ、CMRよりSMRのほうが書込が速かった。
今後は、SMR主流になるのは間違いないという大本営発表が出ますw
WDのファームのほうが賢かったんだろ
あと、茂のメディアキャッシュは非SMRの前世代から使われてたのを忘れるな
>>571
これの場合でも内周外周関わらずMCに乗ったMFTの更新量は同じだろうけど
このコピー処理中にMCから瓦書きした量が簡単に同じになるかと考えると疑問は残る
というのもMCに乗ったMFTがコピー処理中に全て瓦書きされるためには
1ファイル分のMFT更新の瓦書きが19MBの瓦直書きより速い必要があるけど
普通に考えたらMFT更新の瓦直書きの方が遅いと思うんだよね
そうなると遅延は7分固定ではなくOSからの書き込み処理時間に比例
つまり内周の方が大きくなってしまう
>>439 の海門方式詳細によりMFT更新の瓦直書きの方がたまたま速く終わっていたのだろうか？ >>577
やってもた
「MFT更新の瓦直書き」ではなく「MFT更新の瓦書き」な >>569
いや、外周だろうと内周だろうとロスは同じで不思議じゃないと書いたでしょ。
自分で考えるのも大事だけど、少しは人の言うことを信じようよ。
メディアキャッシュ経由の場合に必要になる読み書き時間は以下の合計。
・メディアキャッシュへの書き込み
・メディアキャッシュからの読み取り
・瓦への書き込み
瓦への書き込み時間は直書きと同じだから、差はメディアキャッシュとの往復分、
LBA が外周でも内周でも変わらないでしょ？
メディアキャッシュに残っていてもコピー完了になるというインチキフィニッシュの都合で、
内周の場合、メディアキャッシュに書き逃げしたほうが早く終わるけど、
インチキできる時間は溜め込んだ量×メディアキャッシュへの書き込み速度なので、
これも結局外周と内周で同じ。 >>573
それは憶測であってぜんぜんわからないよ。
自分はバンド単位アドレス変換に意味を見出せなかったので
もし変換しているならセクタ単位だろうと思ったが、
不正電源断問題の件で意味があることがわかったので振り出しに戻った。
正確には、あの話題を見たときには意味はわかっていたんだけど、
アドレス変換なしがそんなまどろっこしいことをしているとは思えず
何か対策をしているはずだと考えたので、すっかり忘れていた……ｗ
Trim はアドレス変換なしでも役に立つことはあるので確かな根拠にはならない。 >>579
海門の場合全部MCに書かれるって事？
だとするとMC書きの後にMC読みと瓦への書きが必要になるから7分では済まないような？
外周では最悪3倍、良くても2倍位は時間かかりそう
それに海門がMCに書く必要の無い数十GBものデータを丸ごとMCに書いてしまう程
低技術だとも思えないけど、まあ無いとは言い切れないけど >>581
新しい知識を得たなら、過去の自分が読み取れなかったこともある可能性を考え
関連レスを読み返すくらいしようよ……。
>>546 の三行目からとか >>554 とか >>566 の最後とか。
最後のは言葉足らずだったかもしれんので補足すると、
42GB 分メディアキャッシュ経由になったらロス７分ってことね。
コピー終了時に 20GB 溜まったままでメディアキャッシュ行きになったのは 62GB だとか、
WD60EZAZ も 8GB は経由したので 70GB だとか、もちろん正確なことはわからんけど。
シーゲートが振るわなかったことについては
「1ファイル19MB程度」がたまたま苦手なサイズだったって可能性もある。
ファイルがでかいとシーゲートのほうが少し速いんじゃなかったっけ？
まあ、とくに安定度とか、随分 WD に水をあけられちゃったねって気はするけどｗ なんか前スレの流れに戻ってきたな…
またこいつら叩かないといけないのか?
>>582
42GB普通に断片的にMCに書かれるなら
MCからの瓦への書き込み時間が瓦直書きと同じとはならなくね？
MCから瓦へは瓦書きされるのが基本なわけで
MC上でバンドデータが丸ごと出来たなら例外的に
瓦直書きと同じ様に書けるかなって話が >>581 だったんだけどね いつまで「僕の考えるさいきょうのSMR HDD」語るつもりなの？
メーカーが仕様を公開してないんだから、議論が終結する事は無いんだよね
>>584
瓦全体が同一ファイルで占められるときだけ直書きで、その他は全部メディアキャッシュ行き。
WD が直書きできるデータ列なら必然的にメディアキャッシュ上に瓦ひとつ分丸々集まる。
不正電源断があっても失うものはないのでそのまま書くだけでいい。
ってのを想定。
>>581 は全部メディアキャッシュ行き前提だったみたいだけど、その場合も同様。
そのまま書けないデータ列なら WD も直書きできないので同じくメディアキャッシュ行きになる。
その場合の瓦書き換えは Trim や方式の差（あれば）が出るけど、
WD が大半直書きできるケースなのでそこまで影響ないと思う。 >>585
明らかに矛盾する説は否定できる。
実測データに合わない説も否定できる。
別に正解を決めようとしてるわけじゃないけどね。
やってそうなことがわかれば上手な使い方のヒントにもなるんだし、ほっといてちょうだい。 >>586
瓦全体はバンド全体って事かな？同一ファイルってのは見当違いじゃね？
ファイルってのはosが勝手に作った概念だからHDDはまったく知らない
つまりSMRはファイルに全く依存しないで動作するし、しなくてはならない
確かにMC上にバンド丸ごとのデータが出来ればその分は瓦直書きと同じ様に書けるかも知れないが
少しでも足りなかったり溢れたりしたらその分は瓦書きしなくてはならなくなる
そんな運ゲーのような話で7分固定の差が生まれるのは難しい気がするし
MC上のバンド丸ごとのデータを直書きし損ねる程
海門が無能でないとならないのが厳しい気もする >>588
スマン。リアル瓦のイメージでバンドひとつ分のつもりだったんだけど、
瓦部分全体にもとれちゃうね。
で、ファイルうんぬんについては、
そもそもが管理情報アクセスで直書き判定が邪魔されるって話なんだし、その境界と思ってくれ。
話がややこしくなるし確証もないので今まで書かなかったけど、
実は管理情報はある程度まとめ書きするっぽい説もあるので
ファイルサイズからの推測以上に条件は合うのかもしれない。
運ゲーでもないよ。WD が大半直書きできてるのだから、大半は丸々集まるはず。
シーゲートが無能かは……わからんｗ >>589
リアル瓦で言うならセクタが瓦でバンドが1つの瓦屋根で瓦領域全体は複数の瓦屋根で出来てるってところじゃね
管理情報アクセスで直書き判定が邪魔される可能性があるのはわからんではないが
動画のシーケンシャルライト中に数KBのテキストファイルの書き込み挟んだだけで判定崩れるのと
同じなのであまりに脆弱じゃないかとも思う
運ゲーだと言ってるのは例えばバンドサイズが30MBだとして19MB1個だと11MB足らず
2個だと8MB溢れるわけでその端数は瓦書きせざる負えなくなるでしょ
瓦書きは内周外周で速さやかかる時間は変わるだろうし
その端数が出なくするには42GB丸ごとMCに乗らないといけないがそんな都合の良い話にするのかと
管理情報まとめ書きってosはそんな事するわけ無いと思うけど
MCからの瓦書きって意味ならある程度まとめられてる可能性もあるだろうね >>590
＞リアル瓦で言うならセクタが瓦でバンドが1つの瓦屋根で瓦領域全体は複数の瓦屋根で出来てるってところじゃね
ああ、スマン。瓦書きとか書いてたらなんか変なイメージになってた。
正確には瓦屋根書きか……。セクタというかトラックが瓦だね。
＞動画のシーケンシャルライト中に数KBのテキストファイルの書き込み挟んだだけで判定崩れるのと
＞同じなのであまりに脆弱じゃないかとも思う
いや、それはクラスタが割り込まれて確保されることがあるので、管理情報より難しい。
まあ、メディアキャッシュ行きにして
それ以外の部分がバンド分溜まったときに混ぜれば一度に書けるけど。
＞その端数が出なくするには42GB丸ごとMCに乗らないといけないがそんな都合の良い話にするのかと
連続 LBA アクセスがバンド全体を占めたとき（正確な表現にするねｗ）だけ直書きするなら、
残った部分はその都合のいい状態になってるよ。WD が直書きできるパターンならね。
＞管理情報まとめ書きってosはそんな事するわけ無いと思うけど
やっとソースみつけた。ExamDisk の人だったのか……。
http://yosh.s602.xrea.com/sp/aft/
アクセスパターンの表の合計を見て。詳細は省くが括弧内が管理情報アクセス回数。
ファイル数よりぜんぜん少ないでしょ？
管理情報は、ちょっと考えただけでもファイルひとつにつき、
$MFT 内レコード、$Bitmap、ディレクトリ本体とその $MFT 内レコード、$LogFile、
ほとんどはファイル作成時と完成時の両方で更新する必要があるし、
クソ真面目にやってたら遅くて仕方ないんだと思う。
FUA 付いてるのでライトキャッシュは効かず NCQ も無力（とりあえず CMR の場合）。 >>591
つまり海門の方だけ何故か最後の42GBだけ全部MCに乗ってるんじゃないかって事？ あーもういや。うちの海門8TB、昨日の夜から初めて15時間で800GBくらいしか
コピーできてないんだけど。
この前の週末には600GBを3時間くらいでコピーできた。
挙動がよくわからないから予定が立たんわ。
WDだとこういうことないのかなあ。
>>594
SMRは数十MB以下の小さいファイルを数十GB単位で大量に書き込むと
とんでもない時間がかかる事があるというのが定説
但しどれ位時間がかかるのかは謎
現状上記に当てはまる場合は待つしかないだろうね >>594
8TBコピーするのに4日か。使い物にならんなw まあある意味公称スペック詐称にも近い気がするが
そういやCMRでもランダム書き込み時の最低速度なんて
書いて無かったからギリギリセーフかw
論理アドレス空間上のファイルの断片化は物理アド空間へ波及し
物理アド上の断片化という二次災害を産み出すのではないか？
論理アドレス物理アドレス分離は余計なカオスを作り出すだけちゃうか？
SSDのような書込消去制限があるならともかくHDDで何故こんなカオスを生み出す方式を採用したのかと
>>593
わかんないかあ。
aabbbbbbbccdddddddddddee 文字が変わるタイミングで管理領域アクセスが割り込み
111122223333444455556666 対応するバンド
の場合に、「連続 LBA アクセスがバンド全体を占めたときだけ直書き」するなら
バンド 2 4 5 が対象になる。
で、残ったメディアキャッシュ行きになるのは
aabb----bccd--------ddee メディアキャッシュ行き
1111----3333--------6666 対応するバンド
だから、「不正電源断があっても失うものはないのでそのまま書くだけでいい」
都合のいい状態になってるでしょ？
図を書くまでもないんだけどｗ >>594
空き領域の断片化具合やファイルサイズによって変わってくるのは仕組上どうしようもない。
でも、遅くなる程度や激遅状態になるまでのボーダーは WD のほうが大分優秀っぽいので、
予定が立たない程ブレることはないかもしれないね。
もちろん、状態や作業内容にもよるけど。 >>601
それはつまり海門の方だけの断片的にMCに行きになったって話だよな
それが集めると42GB位あったんじゃないかと
俺が理解出来てないのはそのMCにいったデータがどういう扱いになると
7分固定の遅延になるかってとこ >>603
「そのMCにいったデータがどういう扱いになると」に端的に答えるなら
「RAM に読み込んでバンドにそのまま書く」。
>>579 を読み返して欲しいが、↑の時間は７分に含まれず、
＞・メディアキャッシュへの書き込み
＞・メディアキャッシュからの読み取り
の合計が７分なので念のため。 >>604
「RAM に読み込んでバンドにそのまま書く」
ってのがなんで出来るのかわからない
MCに書いたらosに書き込み完了を返してから非同期にMCから瓦に書くんでしょ？
だとしたら >>601 に書いてある通りMCに乗った後のデータが瓦に直書きされた
後にMCから瓦に書く事が往々にして発生するわけで
その状態でMCから瓦のバンドにそのまま書くなんてしたら瓦のバンドのデータぶっ壊れると思うんだけど >>605
ああ、MCに乗った次に瓦に直書き開始されるのは次のバンドの開始だろうから
MCに乗るのは必ずバンド丸ごとになるって事か >>604
でも多分 >>439 を見る限り海門はバンドの開始じゃなくても瓦に直書きできちゃうんだ
WDもなんだろうけど SMRに関してはseagateのほうが歴史あるからいいのかと思うけど
そうでもないんか
>>608
流石に一長一短だと思うけど
如何せん公開されてない仕様が多すぎて判断出来る人がいない
というか仕様が複雑過ぎて公開されてもなかなか判断つかない気がするが >>607
それ、書き換えのときはもちろん有効だけど、直書きのときは微妙だよね。
結局書き換えになったときに損してしまう。
まあ、やっちゃってるから遅いのかもしれないが……。
あと、話がややこしくならないようレスしなかったんだけど >>571 はないと思う。
$MFT なら確かにファイル個数依存なんだが、
大変なのは飛び飛びに断片化しまくるディレクトリ。
今回のケースでは恐らくデータ本体の間に割り込むかたちでクラスタ割り当てされるので、
外周と内周でロス時間が大きく変わるはず。
ちなみに、無駄に書き換えるようなことはしてないとすると、
キャッシュというからには使用頻度や最低でも最終使用時刻は考慮してるだろうし、
コピーのような規則正しいアクセスなら管理情報を何回も書き換えするようなことには
ほとんどなっていないと思う。 あーもういや。いまだにコピー終わらず。54時間で3TB。
こんな糞HDD製品化しちゃだめだと思う。
>>610
直書きの時は微妙って何と比べてだ？
よく言われてるバンド丸ごと更新と比べたら完全上位互換だと思うけど？ >>612
話を飛躍させすぎたな
そもそもなんでバンド丸ごとのシーケンシャルライトなら瓦に直書き出来ると言われてたかは
瓦書きの際に再書き込みが必要な瓦部分が全部更新対象であれば退避して書き直す必要が無いからで
それがバンド丸ごとだと思われていたから
但し >>439 で海門は瓦書きの際に再書き込みするのは更新対象の
データのアドレスからバンド終端までで十分だと言っている
それはつまりシーケンシャルライトの直書き出来る条件もバンドの終端を含んでさえいれば
開始のアドレスは何処でも良いと言う事になる
バンドの終端さえ含んでいれば1MBでも瓦に直書き出来るって事 >>610
キャッシュってMCの事？
いや一般的なキャッシュって言ったら溢れて機能しなくても
実用は出来る程度のパフォーマンスはあるものだけど
MCは溢れたら終わりだからな
MCに書かれたばかりだから瓦書きはまだしないでおこうなんて
悠長な事を言ってられない側面もあると思うけど
キャッシュの癖に読み込みは大して変わらんしな
シークが増えてむしろ遅くなる位で >>611
大変だねー。
自分も今 CMR で大整理してるが、
コピー元とコピー先の両方が外周になるケースがないのか
ずっと 100MB/s くらいしか出なくておせーとか贅沢なこと考えてたよｗ
ファイルサイズの傾向はどんな感じ？ >>612
理由は次の行に書いたでしょ……。
>>601 の例で言うと
--bb-------d----------ee 直書き
aa------bcc---------dd-- メディアキャッシュ行き
1111----3333--------6666 対応するバンド
みたいになるわけだけど、結局あとで読み直して書き換える羽目になる。
>>614
$MFT 以外にディレクトリもあるよ。ないと階層構造が作れない。
ちなみに、NTFS の方言ではインデックスという。
知らないと chkdsk のメッセージが意味不明。 >>615
確かに一般的なキャッシュとは違うね。RAM のもだけど。
でも、何回も使われるものや最近使われたものは
また使われる可能性が高いだろうと予測するのが大事という点では同じ。
瓦の書き換えが大変だからこそ、
管理情報のようなものはキープするようにしないととんでもないことになる。
だからといって溢れたら元も子もないので判断は本当に難しいと思う。
あ、キャッシュなら必ず何か考慮してるだろうというような書き方は語弊があった。
CPU のキャッシュは考慮する余裕がないのでランダムに捨てたりもする。 >>617
いやMFTに階層構造を書けば良いだけでは？？
とりあえず NTFS インデックス でググってみって
これといった記述はなくたまに MFT（インデックス）みたいな記述が引っかかるだけだぞ >>617
そう、その場合では瓦書きが発生してしまうので内周外周問わず
7分固定で遅延する事が無くなってしまう
だからそんな事は起こって無いのでは？という話になる
何れの瓦への直書き判定にせよ不揮発領域に書く前に
揮発領域に数十MBはキャッシュしないと出来ないと考えれば
判定の際に数KBの割り込まれた書き込みを除外して判定する位
出来てもおかしく無いのでは？ >>618
通常のMFTが頻繁に書き換えられるケースから考えると
わざわざキープを意識する必要は無かったんじゃないかと
例えば4kのファイル千個osから書く場合
で、仮にMFTも千回書き換えられるとすると
MCへファイルとMFTが交互に千回計ニ千回書かれる事になるけど
もしこの二千回の書き込みが最初の4KBのファイルの瓦書き中に終わったなら
MFTの瓦書きは一回で済むし次のMFTの瓦書きまで及んでても
MFTの瓦書きは二回で済むのでわざわざキープを意識する必要は無かったのかなと >>622
OS側のキャッシュが >>562 で言ってるWDより海門が7分固定で遅い要因に関係してるのか？ 381 名前：Socket774[sage] 投稿日：2019/06/06(木) 17:23:05.26 ID:8YpWKtNh
ST8000DM004に動画ファイル6TB分をFastcopyで移動したけれど、
特に問題もなく移動終わった。
ファイルサイズは1GB～14GBくらい。と、ほぼ同数の数KBのテキストファイル。
コピー元を内蔵SATA、コピー先はUSB3.0の外付け。
3セットやったけれど移動終了時のFastvopyの平均速度表示は50MB/Sec台。ベリファイあり、移動の都度消去の設定。
SATAやUSBのコントローラが被らないように東芝のCMR8TBとも同時にやったけれど、
こっちも50MB/Sec台だったのでうちの環境ではこれが速度上限っぽい。
コピー元はみんなWD青や緑の6TB
387 名前：Socket774[sage] 投稿日：2019/06/07(金) 00:21:15.58 ID:Ruw2ipLL
>>381
そういう動画ファイルのサイズだったら俺のとだいたい同じなんだが
PC1のCMRからPC2のCMRにイーサネット経由でコピーしても平均でほぼ100MB/秒
早い時は長時間120MBもでコピーしてるから、50MB/秒とかやってられんわ
サイズが巨大なんだから500MB/秒くらい常識になってもらわんと困る
390 名前：Socket774[sage] 投稿日：2019/06/07(金) 10:59:54.40 ID:gNEtKEr4
>>387
GbE使ってたら118MB/sにしかならんぞ なんだかんだでスペック上の数値だけ。
うちも調子が良くて50-60MB/s。遅いときは200バイト/sとか。
うちの場合、
50MBくらいのファイル 50MB/s
20MBだと 20MB/s
10MB以外 1MB/s以外
って感じ。
かなり大きなファイルじゃないとまともに使えない。
たとえば、3TBSMRドライブが残量約55GBを残してほぼいっぱいになっていて
残量約55GBのすべてのセクタが約14000個のSMRブロック（ひとつのSMRブロックが非公開なので類推で200MBで計算)に分散している最悪のケースの場合、
残量約55GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで書き込める環境だとしても、空領域55GBを書き込むのに約8時間、実態として2MB/sという低速での書き込みになるのだ
>>627
SMRブロックはバンドと言われていてどっかで平均30MBって書いてあっか気がするが 76時間経過で4TBコピー。残り550GBだけど、さっき残り100日とか無茶な数字出たw
今はのこり1日だってさ。4.5TBコピーするのに100時間っておかしくね？
>>630
CMRにしたらおかしいけどSMRだったらありうる数字
そこを乗り越えたら普通に使えるから！がんばれ！w うちの ST8000DM004 は 一杯になった MC が空になるのに 5分かかる（かける）
後続するアクセスがヒットすることを期待しながら1分で20%のペースでフラッシュされる、感じかな
古いバンドから順にフラッシュされるからディレクトリエントリを含むバンドはずっと MC に居るだろうね
あと、連続でベンチマークを実行するときは MC の空き具合を考慮しないと結果がマチマチに
SMRのHDDにどういうデータを保存してるか語ろうぜ（意外と向いてないデータとか参考になるかもしれん）
おいちゃんは手持ちのPS2ゲームのISOを置いてる
SMRは、19MB超のファイルのみなら速度低下しないみたいだから、
・高解像度画像
・動画
・ハイレゾ音楽ファイル
あたりなら問題なく使えるかもしれないね。
ts抜きチューナーで録画したテレビの倉庫用にSMR使ってるけど何の不便もない
>>634
たぶん駄目だと思う。100mb超のファイルばかり保存する用途じゃないと。
最低でも50mb >>636
ID:OI3mOdrWaの書き込みを見る限り、19MBで大丈夫そうに思えますが、何か見落としてますかね？ >>637
瓦ブロックが30Mとして30-19＝11がどう使われるかがちょっと気になるかな。物理論理の変換が途中に入っても多分詰めて使われる(殆どは詰めて使われる)だろうし、数十Mのファイルが殆どで大量書き換えが無いなら問題無いんじゃね？
取り敢えず注意が必要そうなのは
・システム(普通SSDだしw)
・開発環境系(srcはサイズが小さい)
・大量の写真／画像(サイズによるが)
・RAID／プール(倉庫専用プールなら△？)
後確証ないけど読み書きバッティングすると何か有りそうなんで…
・会社でoutlook使わされてるが、あーゆーのもヤバイかも。あいつI/o負荷高すぎる
・定期的にハッシュチェック(手動や記憶域プールとか)するような重要倉庫なら、スケジュールに注意 後当たり前ダケド各種キャッシュやDBはダメか
まぁ今時システムSSD相乗りもしくは専用SSDにするだろうから、SMR所かHDD自体も避けるだろうケドwww
>>637
これまでの経験。
海門SMRでテラバイト級コピーしていてコピー速度見てると
20MBのファイルコピーしてるとこで速度下がるから。
いろいろ要因はあると思うけど。 >>641
× 海門を買わなきゃいいだけの話
○ SMR を買わなきゃいいだけの話 >>642
まさにそうなのだが、海門はもうほとんどCMRの選択肢ないから一緒くたでいいかと思ってw >>643
海門だと鉄狼ならCMRだよ
WDは赤にも混ざってるので品番による
ファームバグとかで盛大にトラブり一般に認知されて原発共々消えてなくなれば良いのに >>638
30-19についてはWDの >>514 に関しては >>546 で今回の書き込みでは
たまたま隣接するファイルの書き込み先のアドレスが繋がっていてSMR内では全部シーケンシャルライトと
認識されて瓦へ直書きされたのではないかと言ってる
俺もその可能性が高いと思ってて理由は >>514 の書き込み速度が速すぎるからな
CMR より速いし >>644
MCからの瓦書き中にデータ破損する可能性があったりしたら
SMRが無かった事にされる未来もあると思うけどな
だからこそメーカーも細心の注意を払ってると思うが >>638
読み書きバッティングすると何かありそうってそれは風評被害だろw
CMRと同じ様に遅くなるだけでしょ
確かにバックグラウンドでされるMCからの瓦書きと
バッティングして遅くなる事はちょいちょいあるだろうけど
そもそも例えばウィルス対策ソフトなんか入れてると
CMRでも読み書きバッティングなんて日常的なものになるからな
そんな程度の話でしょ 実体としての中身がJPEGファイルの集まりであるMotionJPEGの
AVIコンテナファイルが50GBから100GB超で大量にあるんだけど
コピー頻繁に繰り返す仕事してるんだがどうなるんかな
(あ、「ボクの考えたSMRの仕組み」を語る人のレスは要らないです
SMR持ってる人で似た環境で実際にコピーとかした経験ある人が
もしいらっしゃらなければ、推測論は不要なのでスルーでどうぞ)
そんな判断も自分の頭でしようともしないまま仕事で使ってるのか
そら頭使った話はついていけんわな
>>649
お前のレスは要らないと言ったはずだ、なぜスルーしない? >>650
お前がなww せっかく安価も付けなかったのに >>648
WD60EZAZを使っている感じでは
空き容量が僅かな状態での頻繁な書き換えをしなければ極端な速度の低下は起きないかなと
それ以外はCMRのものより遅いとは感じにくいかな
とは言っても他の環境ではどうなるか分からないから結局のところ自分で買って試してみてと無責任なことしか言えない 見た目1ファイルでも実体は数十万のJPEGファイルの集合体のコンテナだから
同じ容量の他のファイルとはちょっとコピー時の挙動が違うかと思って尋ねてます
>>652
ありがとう
やはり自分で試すしかないものか
いまあるCMRも全部WDで揃えてるし、とりあえずはseagateよりかWDだろうか
>>651
はぁ?
アンカーつけなければ悪口を言っていいのはお前の幼稚園内だけ
お前ら数人だけでグダグダ無能な推論繰り返すのは勝手としても
お前らと関わりたくないと宣言してる側に一切レスすんなや！ >>619
いくらでも大きくなり得るものをファイルレコードと同列には扱えんよ。ファイルと同じ。
実際 NTFS ではフラグが違うだけでファイルと同様に扱われているので
基本的にはクラスタが割り当てられる。
>>620
だから「連続 LBA アクセスがバンド全体を占めたときだけ直書き」なら問題ないでしょ？
WD ができてることをなぜできないのかは知らんが、現実に WD より遅くなってる。
これは、実際に技術レベルが低いか、
今回はたまたま負けたが場合によっては逆転するケースがあるかしかない。
でも、そんなことはどうでもいいんだよ。
外周でも内周でもロス時間が変わらないという現象を説明できる説があり、
ほかに思い付かないのに「それくらいできてもおかしくないのでは？」
なんていう曖昧な理由で否定してたら答は見えてこないよ。
何もこの説が絶対に正しいなんて思ってない。
>>621
それは結局キープされてたってことでしょ？
それに、使い込まれてくるとレコードが飛び飛びに使われるのでそんな単純な話ではなくなる。
MFT レコードなんてファイル１万個で 10MB なんだし、
余程総ファイル数が多くない限り常駐してていいくらいだよ。
そしてアクセス頻度を見てれば実際にそれに近い状態になるはず。
暇になったら瓦書きしてもいいし、
それこそ一般的なキャッシュのようにいつ捨ててもいいものとして残しておいても役に立つ。 >>624
FastCopy の転送速度は「転送量÷すべての作業にかかった時間」なので、
ベリファイしてたらそりゃ数値は下がる。
CMR 同士でもどちらかが内周だったら（コピー先のほうが影響は大きい）そんなもんでしょ。
>>628
>>627 は極端に思えるけど、
空き領域の断片化が進むにつれ一歩一歩確実にその状態に近付いていく。
今システムドライブを調べたら空き領域の断片は 7000 個。
録画用ドライブはかなり使い込んでるにも関わらず事前確保の成果か 1000 個程度だったが、
なんの対策もせずニコ生同時録画とかやってるドライブはなんと 50000 個ｗ
SMR だったらかなりやべー状態なんだろうなあ。
>>632
20GB を 200MB/s で読んだり書いたりするのに 100s。
読みと書きで二倍、書き側は内周なら二倍、この時点ですでに期待値 250s。
実際にはメディアキャッシュ容量以上のバンドに書くことになるし、
書き換え方式によってはもっと手数がかかるし、
ペースを考えてるというより全力でそれなんじゃないかな。 >>653
推論繰り返してる一人なので無視してくれてかまわんが、
HDD にとってはファイルの中身なんて知ったこっちゃないので、
オールゼロだろうとテキストファイルだろうとエロ動画だろうと変わらん。
実経験のある人の答を期待したいといっても
MotionJPEG なんてマイナーなもん扱ってる人そうそういないだろうし
答が返ってくる可能性は限りなく低いよ。
たとえ扱ってたとしても環境も作業内容も人によって違う。
完全に同じ状況なんてまずないんだから、
何が影響して何が影響しないのかを判断しなければならない。
そのためには多かれ少なかれ推測が必要。
あ、一段落目も推測だから信じなくてもいいよ。
>>652 さんも同様の推測を元に答えたまでで
恐らく MotionJPEG を扱ってるわけじゃないと思うけど。 >>655
いやMCに乗った物を残しておいても役には立たんでしょ
それがもしシーケンシャルデータの断片だったらリード時のロスにしかならんし
なによりMC溢れたら死ぬわけだからSMRとしては一刻も早く書き出す方向で考えるべきでしょ
とはいえ当然osになるべく影響を与えずに瓦書きすべきではあるから
その点のトレードオフな調整はあると思うけど
例えばWDは1GBまでは積極的に瓦書きはしないけど海門はそれ以下でも積極的に瓦書きするとか
MFTだったら常駐させた方が良いってそんなんHDDは知らんしな
書き込み頻繁だから残すってもそんなデータ普通
MFT内位にしかないわけでその為だけに全てのMC上のデータの
書き込み頻度管理までするのかは疑問
だってそれ管理してもしなくてもMCが溢れる程度は変わらんしな >>655
あと既知かもしれないけど >>9 は見といた方が良い
海門の SMR への大量書き込みを速度変化まで計測してる とはいえMC上に複数のデータがあった場合にバンド単位で更新が古い順に瓦書きする
位のソートはしてるかもしれないけどMC上に一個しかデータ無いけど更新が新しいから
瓦書きは保留するなんて判断はしないと思う
>>655
ディレクトリメタデータについてはosから確認って出来ないでしょ
だからファイルとまったく同じ領域にに書かれるのだとしたら
osから見えるストレージ残量の辻褄が合わなくなる
なのでディレクトリのメタデータがMFT外に書かれるとしても
予め確保しておいた管理領域内に書かれると考えた方が妥当ではないかと Western Digital
WD60EZAZ-RT (6TB)
https://www.dospara.co.jp/5shopping/detail_parts.php?bg=1&br=13&sbr=172&ic=458341&lf=0
お客様のレビュー
お勧め度: ★★★★
[2019/05/31] ニックネームなし
win10 pro 64bitにて、動画・音楽・写真のデータ保管用として使用。SMR方式になったからか、大量データを書き込む際に時間が掛かる。
終了予定時間が表示されるがその表示がよくフリーズする（裏で書き込み自体は動いていて、
放っておくと表示が正常に戻る）書き込みの挙動は不安になるが、異音や異常な温度上昇は特にない。音は静か。
やっぱSMRだからWDでも変わらんかー妥協するしかねえな >>658
＞だってそれ管理してもしなくてもMCが溢れる程度は変わらんしな
ランダムに更新される管理情報の瓦書きがどんだけ大変だかわかってる？
その分ほかの作業時間が削られるんだから溢れやすさに大いに影響する。
常駐させとけば、常に CMR 同様にアクセスでき、それ以上何もする必要がないんだよ？
そして、アクセス頻度を調べなければ、
管理情報なのか小さいファイルなのか大きいファイルの断片なのか区別できない。
なんなら区別する必要もない。
管理情報レベルに書き換えが繰り返されるセクタがあるなら
ファイルの一部だろうとそこは残しておいたほうがいい。
調べる価値あるでしょ？ っていうか調べないと話にならないレベルだと思う。
＞なによりMC溢れたら死ぬわけだからSMRとしては一刻も早く書き出す方向で考えるべきでしょ
吐き出すのとキープするのは相反じゃないからね？
吐き出しつつキープし続けてもいい。
「いつ捨ててもいいものとして残しておいても」と言ったでしょ？ >>659
前に見たけど、SMR の挙動的にはテスト１で直書きすることもあるのがわかるくらいだね。
ほかのテストはコピー総量が小さ過ぎて見所がない。
＞今回は、あくまでも「普段の使用状況」を想定しているので
なので調査方法にケチをつける気はもちろんないけど。
しいて見所を挙げるならテスト３の徐々に速度が上がるところ。
この量なら全部システムキャッシュに入ってもおかしくなく、
実際 CMR ではそうなってるっぽいのになぜ違いが出るのだろう。
出口が詰まってても入れるほうには影響ないはず。
システムキャッシュをスルーする FUA 付き管理情報書き込みが滞ってるのが影響？？
あとはテスト２が CMR からして遅過ぎないかとか。
うちではこの程度のファイルサイズで遅くなる感じはない。
FastCopy だからでエクスプローラーだとこんなもんなのか？
……てな感じにシステムキャッシュやエクスプローラーの挙動考察になってしまい、
つまりはそれが解明しない限り SMR 考察に進めないｗ >>661
だからさあ、ディレクトリが普通にクラスタとして割り当てられるのは事実なの。
クラスタマップの見られるデフラグソフトとか使ったことない？
システムが勝手に書き込まないデータドライブで chkdsk して最後のまとめを見て。
信じてないようだけどインデックスってのがディレクトリ。
何かディレクトリを作ってもう一度 chkdsk。インデックスが １ 増える。
これでインデックス＝ディレクトリは信じてくれるよね？
ただ、これはファイルにも言えることだが
小さいと MFT レコード内に収まりクラスタが割り当てられない。
「基本的には」と言ったのはこの意味。
さっき作ったディレクトリの中に小さいファイルを十個くらい作って chkdsk。
インデックスの使用量が 4KB 増え、利用可能アロケーションユニットが 1 減る。
いい加減疲れてるんだけど、この件に限らず、
矛盾点の指摘や間違いだとわかるソースの提示もなく
勝手な憶測で否定するなら、もう相手しないよ？
まったく発展性がないし、こんなの続けてたら周りからうざがられて当然だ。 12000円も出せば買えるんだから
さっさとかえばいいじゃんw
百聞は一見にしかず
>>663
他の作業時間って言うのはより具体的には他の瓦書き作業時間の事でしょ？
だからMCの空き具合に関してだけ考えた場合
MC上に他に多数の瓦書き対象のデータが乗ってる場合だけ
MFTやディレクトリが複数回瓦書きされないようになってればよく
それ以外の時の考慮は不要
むしろSMR側から考えた場合MFT等が無いような使われ方を考えたら
基本的にMCは空にしておくに越したとこはないでしょ
因みに瓦書き一回は大体2秒位とどっかで見た気がして俺もそんなものだと思ってる >>666
考察できる人が買えば適切な実験をして色々判明するんだろうけど、
考察できる人ほど買う気のなくなる代物なのでってのはあるなｗ >>667
だから「吐き出すのとキープするのは相反じゃないからね？」と言ったでしょ？
このフレーズ何回目だよ。
あなたは反論しているつもりなんだろうけど、
相手の言うことを理解しようとしないから反論になってないんだよ。
なるべく早く吐き出すべきなんてことは端からわかってる。
吐き出したとしても残しておけば色々役立つことがあるんだが、
説明しても、どうせ理解不足からおかしな反論が来て
ぐだぐだになることが目に見てるのでもうしない。 端から見てるとどちらも俺理論なんだから大差ない様に見える
推測で話をするしかないんだから俺理論は仕方がないと思うんだけど、
俺様正解理論はわざわざここでする必要無いだろと思う
スレ読んでる人のほとんどは遅くなるHDDの型番が知りたいのであって
俺理論はどうでもいいからな
>>672
それは内容を理解しようとしてないからだと思うよ。
もちろん興味がないならそれで構わないし、
とくに今回は我ながらぐだぐだになったので読む気が起きないのもわかるｗ
まあ、技術的に興味があってこのスレを最近見始めた人になら
それなりに参考になることもあったかなとは思うけど。
>>673
とりあえず、自分は俺様正解のつもりはないよ。
どのような挙動なら >>512 さんの実験結果のようになるか考察し
可能性のひとつとして >>546 を挙げてみただけ。
そうそう、>>520 さんのグラフがすごい参考になった。遅ればせながらありがとう。
ある程度わかってる人になら納得してもらえたと思うし、
何かミスがあるなら指摘歓迎、別の案を思い付いたならもちろんそれも歓迎、
なければこれで終わりのはずだった。
……今見返してみると、いきなりおかしな反応してるし、
>>554 みたいな説明で通じる相手ではなかったな……。 >>674
使い方によって逆転する可能性もあり、
誰かの使用結果を見て買ってはみたが、
自分の用途には合わなかったということも有り得るがよろしいか？
もっとも、今のところ WD の完勝で逆転するケースは出てこないみたいだけどｗ
>>675
ならこのスレいらないのでは？
買ってみたものの使いものにならなかったなんてごめんだしな。
個人的には半額なら買ってもいい程度だったのが、
WD のならもうちょい出してもいいかなあくらいにはなったし、大いに役に立った。
まあ、赤に紛らわしい型番でこっそり混ぜるなんてやってる内は絶対に買わないがｗ >>670
キープは瓦に吐き出す機会をあえて逃してMCに残すという事でしょ？
その場合次にMCに同じアドレスのデータが書き込まれるまでか吐き出しを遅らせた期間
MCの容量を圧迫する事だけは間違いないわけで
MCの容量を確保する事以上にメリットのある
MCに残した時の色々役立つ事というのがよくわからん >>677
本当に海門完敗なのか？という疑問に尽きる
いや現状の状況証拠的にそうなのは理解した上で
海門は何かとトレードオフした結果この状況では負けざる負えなかったのでは無いかと
どっかでシーケンシャルリードは海門の方が速かったとかあった気もするけど
それすらハード性能を合わせるのは元よりWDがSMR内部で
バラバラに書いてくれないといけないから
検証は簡単にはいかないっていう 別の大容量化技術が現れたらね
でもヘリウムは怖いのでヘリウムよりはSMRを選ぶ、倉庫用としては
あと今まであった通気口埋めちゃってたりな
まあ大丈夫なんだろうけど
横です
>>678
OSが自前でメモリにキープしてて、それは瓦に逃がすことと背反しない、って話かと思ってたが違うのかな >>679
誤 せざる負えない
正 せざるを得ない
アルゴリズムが単純だから先に市場に出せた、とかはどうだろう >>683
ヘリウムが減少したとして、内部が真空になるわけじゃないよ？大気に含まれる分子と入れ替わるだけだし。
あとヘリウム採用ドライブケースは完全密閉だから通気する穴とかない。
データリカバリやってる会社は分解後のヘリウム再充填までやってるし。
で、SMRドライブだとヘリウム充填されていると特殊な現象でも起きるの？ >>688
でも、ヘリウム充填の設計的保障は5年程度なんでしょ？
倉庫用HDDって普通に10年とか使うから >>689
空気ドライブなら10年後に動くなんて誰も保証してないが、そう考えるなら空気の方が安心かもね >>686
そうなんかな。メディアキャッシュの話をしてたはずなのに
突如OSのキャッシュの話を出されてもって気もするが >>693
いやいや、MCにも乗ってる状態で、それは瓦に逃がす
fs/OS側はメモリ上の管理領域を参照する >>689
トラック密度が高いSMRだと経年変化によるヘッドのアームの歪で
トラックズレ起こすヘッドが出てきそう >>689
ヘリウム抜けたら即死亡じゃないってどっかのレスキュー会社が言ってた気が。
あと、ヘリウムだけ保持系の保証値違うって話あったっけ？ >>695
いずれにせよ、SMRに代わる未来の技術もトラック密度は高いので（以下省略
>>696
＞ヘリウムだけ保持系の保証値が違う話あったっけ
機構そのものの耐久性はSMRもヘリウムもほとんど変わらないでしょ、変わらない前提で話してる
その上で、ヘリウムドライブはヘリウム少しずつが抜けるデメリットがあり、メーカーが設計で想定しているヘリウム抜けの最低保証は5年くらいだと5チャンネルかどこかでみた記憶がある
ヘリウムを使う理由はたしか、高容量化のためにプラッタ枚数を増やすにあたって空気との摩擦を減らして発熱を抑える目的だったと思うけど、
プラッタ枚数が増えれば故障率は高くなるし、ヘリウムが減れば発熱が増えて故障の確率が高くなる。
ヘリウム再注入の手段があるといってもどうするの？完全密封された筐体に穴を開けてヘリウムを補充するの？いくらかかるのそれ？ >>694
うん、当人もそういう事を言っていたのかも知れないけど
SMRはOSの要求に対して動くってだけの関係だから
OSが何をキャッシュしようが割とどうでも良く、結局何を要求するのかって事にしかならんと思うけど
OSがキャッシュしようがしまいが書けと言われれば書くし
OSが自分のキャッシュ読む分SMRから読まなくて済むならそうだろうけど
SMRはリードは苦手ってわけじゃないので別にだし HGSTのヘリウムの特許のなかに溶接してヘリウム密閉と、
メンテナンスでの再シールみたいな内容のやつが無かったっけ？
>>698
>>663の人が言ってるのは管理領域の書き出しを遅延するって話でしょ
対象がCMRでもSMRでも変わらんけど、電源断とかには弱くなるけどヘッドが行ったり来たりせずデータ書き出しを優先できる
OS側のキューイング
で、>>698で何を言いたいのかわからないw >>700
どこからどこの書き出しの事を言ってるのかわからんって話
なのでそこを書かないとしょうがないと思う
OSからSMRなのかMCから瓦なのか
で、改めて >>663 読んで見るとやっぱり後者なんだろうな >>663
>ランダムに更新される管理領域の瓦書きがどれだけ大変だかわかってる？
ああ、これが主な理由か？
いや管理領域の瓦書きはそんなに大変では無いかなと
例えば1回のMCからの瓦書きが2秒だとして
小さいファイル1個追加したらMFTとディレクトリの瓦書きも考慮すると
2+2+2で6秒、ファイル100個だと200+2+2で204秒のうち
どちらもプラスの4秒だけBGで余計にかかる事になると思うが
BGだしそんなに大変だとは思えないけど
なんか他に瓦書きされるものがあるのかね >>703
バッカじゃねーのw
来る日も来る日も
具体的な動作性能で議論せず
ランダムライトで性能ガタ落ちのSMRアゲ
ウソばっかの妄想設計仕様書いて意味あんの?
ん?
どうかしてるってお前ら
の
略 >>704
なるほどね
>>705
いやね、管理領域取り落しても害の少ない方にリカバリー可能なのが、fsのジャーナリングなんだけど、そこらへんの前提まるで分かってないようだからさ…… >>706
ただでさえ評判低い現状なのに
てか
よくもまあ
みじめにならないもんだよね
にくまれ口叩かれてもさ
まあ
じかんを割いてまで
れす付けてるのは評価するが
すんなり納得できる意見が見当たらんから
やめてほしいんよ
めんどくさいから
てってれー＼(^o^)／ WD：普通に使える
海門：ウンコ
ざっと見たけどこれでFAってこと？
CMR 普通に使える
WD瓦 ときどき不安定
海門瓦 ウンコ
こうです
海門の評価終わってるなw
一応海門も大量コピー時しか実害の報告はあがってないはず
確かにWDのそういう報告は見た事ないけど
両方共切断ってのは >>522 にあるけど >>706
そこらへんの前提があるとOSからSMRへは何の追加要求があるんだ？
とりあえずジャーナル用のログも書かれるから瓦書き処理に2秒追加か？ >>705
だよね～
チョイ前は英文資料とか漁ってカキコしていたもんだがSMR云々はもう飽きた。
だって俺的には普通に使っていて問題ないんだもん。 >>712
たとえば、3TBSMRドライブが残量約372GBを残してほぼいっぱいになっていて
残量約372GBのすべてのセクタが約95000個のSMRブロック（ひとつのSMRブロックが平均で30MBとして計算)に分散している最悪のケースの場合、
残量約372GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで読み書きできる環境だとしても、空領域である372GBを埋めて書き込む（全部SMRブロックを書き換える）のに約16時間、実態として１MB/sという低速での書き込みになるのだ 訂正
たとえば、3TBSMRドライブが残量約372GBを残してほぼいっぱいになっていて
残量約372GBのすべてのクラスタ（4KBで計算）が約95000個のSMRブロック（ひとつのSMRブロックが平均で30MBとして計算)に分散している最悪のケースの場合、
残量約372GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで読み書きできる環境だとしても、空領域である372GBを埋めて書き込む（全部SMRブロックを書き換える）のに約16時間、実態として１MB/sという低速での書き込みになるのだ
BSデジタル放送のビットレート最大24Mbps(4MB/s)と、地上デジタル放送最大17Mbps(2MB/s強)の番組を放送画質そのままで録画しようとした場合、
SMRドライブでは>>714で表したように、最悪の場合では1MB/sと低速になるので、リアルタイム録画ではドライブへの書き込みが追いつかなくなり破綻する。
そのときに録画機がどのような挙動を取るかは不明であるが、SMRドライブがリアルタイム録画には適さないことが明らかなのである どっちかというとそんなに頑張らないとSMRのやばい現象が起こせないものなのかと
もっと簡単に起こせないものかね
倉庫用としてドライブ寿命前に次のドライブにコピる際に
SMRだと絶望的だというのが倉庫用として大問題
計算ミス再訂正
たとえば、3TBSMRドライブが残量約372GBを残してほぼいっぱいになっていて
残量約372GBのすべてのクラスタ（4KBで計算）が約95000個のSMRブロック（ひとつのSMRブロックが平均で30MBとして計算)に分散している最悪のケースの場合、
残量約372GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで読み書きできる環境だとしても、空領域である372GBを埋めて書き込む（全部SMRブロックを書き換える）のに約16時間、実態として5.6MB/sという低速での書き込みになるのだ
BSデジタル放送のビットレート最大24Mbps(4MB/s)と、地上デジタル放送最大17Mbps(2MB/s強)の番組を放送画質そのままで録画しようとした場合、
SMRドライブでは>>714で表したように、最悪の場合で理屈上は5,6MB/sの速度なので、
リアルタイム録画１ｃｈ分であればどうにかSMRドライブにリアルタイム録画できることが分かる 再々訂正
たとえば、3TBSMRドライブが残量約372GBを残してほぼいっぱいになっていて
残量約372GBのすべてのクラスタ（4KBで計算）が約95000個のSMRブロック（ひとつのSMRブロックが平均で30MBとして計算)に分散している最悪のケースの場合、
残量約372GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで読み書きできる環境だとしても、空領域である372GBを埋めて書き込む（全部SMRブロックを書き換える）のに約16時間、実態として5.6MB/sという低速での書き込みになるのだ
BSデジタル放送のビットレート最大24Mbps(4MB/s)と、地上デジタル放送最大17Mbps(2MB/s強)の番組を放送画質そのままで録画しようとした場合、
SMRドライブでは上記のように、最悪の場合で理屈上は5,6MB/sの速度なので、
リアルタイム録画１ｃｈ分であればどうにかSMRドライブにリアルタイム録画できることが分かる
「こうなるはず」っていう推測をどんどん積み重ねていって
勝手にダメな仕様に作り固められていってるように見えるわ
そもそも録画のリアルタイムでもそのままデータストリームをHDDに垂れ流したりせんだろう。
そんなことしたらCMRでだってドライブの状態は大変なことになる。
レコのドライブを変なものに換装すると録画でエラー出るようになってきたりするんだし、
SMRを使おうが最悪ケースでも問題無いようになんて設計はしないだろう。
業務用機ならともかく。
>>722
＞CMRでだってドライブの状態は大変なことになる。
だからAVコマンド対応のドライブが推奨される >>686
いや、SMR の挙動についてだよ。>>663 からの流れを追って。
＞吐き出すのとキープするのは相反じゃないからね？
＞吐き出しつつキープし続けてもいい。
＞「いつ捨ててもいいものとして残しておいても」と言ったでしょ？
ちなみに、「言ったでしょ？」は >>655 の
＞それこそ一般的なキャッシュのようにいつ捨ててもいいものとして残しておいても役に立つ。
のことで、「それこそ～」というフレーズを使ったのは、
>>615 の発言から一般的なキャッシュがどういうものかは理解できているようなので
伝わりやすいかなと思い。
このようなやり取りを経ているのに、
なぜ未だに「瓦に吐き出す機会をあえて逃して」という認識になるのか理解に苦しむ。
まあ、あなたも少し会話してみて片鱗を感じ取ったんじゃないかなｗ >>702
それは管理情報を管理情報として認識できたから一回で済んだんでしょ？
どうやって管理情報だと知ったんだ？
アクセス頻度等アクセスパターンを調べたからじゃないのか？
あなたがそれをする必要がないと言うので、
それじゃ管理情報の瓦書きを何回もすることになりかねず大変だって言ってるレスに
無駄なく作業できた想定で大変じゃないってなんだよ……。 >>697
気休めくらいにしかならんかもしれんが、
HGST の SMART にはヘリウム残量と思われる値があり、
２年程使ってる４台のどれも初期値の 100 から減ってないよ。
HGST スレで「減った人いる？」って聞いたことあるけど反応なかった。
製品全体の保証期間と同様、
その年数経ったらいきなりどうなるって話ではないんじゃないかと。
塵混入の心配がないメリットのほうが断然大きいと思ってる。 最悪の状況を再現できるデータとソフトを置いとけばみんな納得するよ
>>725
>>702 を実現するのにアクセスパターンなんて大仰なものは要らないという話
単にOSから書き込み要求があった時にMC上に同じバンドへの
書き込みが残ってた場合に上書きかマージすれば良いだけ
管理情報かどうかなんて関係なく
それをやらない理由はないでしょ >>724
すまん「いつ捨ててもいいものとして残しておいても」
がメリットが全く浮かばずよくわかって無かったわ
いやMCの空き具合にしか意識がいってなかったもんで
で、これはMCの空き具合的にはMCから瓦書きして残さなかった場合と変わらないと思うが
それでもわざわざ残すのはMCが外周でリードが速いからか？
そして捨てるのはいつだ？ 海門SMR8TBはおまえらいくらくらいなら許容できる？おいちゃんは\13000
>>729
いやマージするのは瓦書きする時で良いか、まあそんな感じ >>734
だって必要だから買うんだし、一台にまとめられるのなら４TB2台分にちょっと上乗せするくらいはOK 4TB未満のHDDだと急激にコスパ悪くなるのに、4TB超過のHDDもコスパ急激に悪くなるの何とかしてー
4TBしか買えないじゃん？(米尼10TBを除く)
誰かエロい人、BPBとかにあるNTFSの諸元を強引に書き換えて
クラスタサイズを32MBにして動作確認とかやってくれんかね
もちろんアラインメントもとってだが
OSからの読み書き要求時代が1瓦単位(推定32MB)になれば
「読んでから一部修正して書き戻す」のサイクルが減るから
少しは変わるんじゃないかと思うんだけど
https://en.wikipedia.org/wiki/BIOS_parameter_block#NTFS
BPB以外にも何かあるかもしれんが
最初は試しにvhdとかでやってみてちゃんと動くか確認すれば良さそうだし
なんならntfs-3gとかで、32Mフォーマットが簡単にできるようになってくれれば良いんだが BPBのクラスタサイズと総クラスタ数にあたる数字を書き換えた後、クイックフォーマットができるかどうかかな
エロイ人にお願いするのなら分かるけど
エロい人にお願いしたところで
性的な意味の答えしか返ってこないと思うけど
そもそも問題になる操作が確立出来てないのに解決策を掲示してもな
>>729
まさか、溢れる心配もない軽いケースしか想定してないの？
重要なのは断片化が進んだり複雑なアクセスで溢れる危険があるとき。
アクセスが途切れた隙に（もしくはそうでなくても積極的に）
溜まってしまったものを頑張って吐き出さなければならないが、
吐き出したバンドに管理情報が含まれており
すぐに再度書き換えられたらまったくの無駄になる。
そうならないためには、管理情報を管理情報として認識する必要があるでしょ？
わかりやすいように管理情報としてるが、前にも言ったように
頻繁に書き換えられるなら別のものでも同じことなので念のため。 >>730
ようやく伝わったか……。
外周が速いことよりまとまっているのでシーク時間が短くなることのほうが大きい。
信じてくれたかわからないがディレクトリはバラバラに散らばりがちだし、
$MFT も断片化することがある。
でもそんなのはおまけで、瓦書き換え時に例の面倒な手順を踏んでいるのだとしたら、
再度書き換えが必要になったときに単純な書き込みで済むメリットが大きい。
バンド丸ごと取っておく必要があるが。
元々バンド単位で管理しているような気がしないでもないけど、
集める手間が省ける代わりに有効なセクタの割合が少なくなるのがもったいない気もする。
変わったところでは、そのセクタ（バンド）が頻繁にアクセスされていたという統計情報が
あとで参考になるかもしれない。この場合、データ自体は捨ててしまってもいいが。
いつ捨てられるのかは状況による。
アクセスが繰り返されているなら「捨てられないもので一杯になる」直前まで残っているだろうし、
そうでないなら「より有用なものを優先して残すため」に捨てられる。
どれを残しどれを捨てるべきか判断するのが重要であり、また難しいところ。
「捨てられないもの」の中でどれから吐き出す（捨ててもいいものに格下げ）べきかも同様。
CPU のキャッシュなんかは高速に処理する必要があるのでやれることは限られるが、
HDD なんて待ってる時間がほとんどみたいなもんだから色々工夫する余地がある。 >>738
クイックフォーマットでもそこらへんは再構築すると思う。
エクスプローラでのフォーマットなら初期値として出てくるかもしれんが
（ディスクの管理のフォーマットの規定値も意味は同じ）、
想定外の値をそのまま使ってくれるかはわからない。 【即時】金券五百円分とすかいらーく券を即ゲット
[一] スマホでたいむばんくを入手 iOS https://t.co/ODBSuZf84d Android https://t.co/5Z27FV6m66
[二] 会員登録を済ませる
[三] マイページへ移動する
[四] 招侍コード → 入力する [Rirz Tu]（空白抜き）
今なら更に16日23:59までの登録で倍額の600円を入手可
クオカードとすかいらーく券を両方ゲットしてもおつりが来ます
数分の作業でできますのでお試し下さい。 👀
Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01) >>741
溢れる危険があろうが無かろうがMC上にある同じバンドに含まれる
書き込みデータは一回の瓦書きで全て解決される
その上でアクセス解析までして何をどうする？
そもそもアクセス管理って全てのバンドにアクセス時のタイムスタンプの配列でも紐づけとくって事？ >>744
しないんじゃないかな。
メジャーなものに特化した解析も考えられなくはないけど、
アクセスパターンはどれも似たようなもんだろうし汎用的な対応で十分だと思う。
なんかでやってるっぽいベンチマークでいい結果が出るような対策も難しそう。 >>746
どうやらあなたは脳のキャッシュ容量が少ないか
もしくはどの情報を残しどれを捨てるべきか判断するのが苦手っぽい。
>>729 の二行目以降の「こうやってるはず」には具体的に反論されなかったのだから
そこには異はなかったと判断し忘れよう。
その上で、最近アクセスされたバンドは >>741 なので
重要度高でキャッシュに読み込みじっくり考察してみてくれ。
「こいつわけのわからんことばかり言ってる」というような疑念があるなら邪魔なので捨てよう。
難しいかもしれないが「自分は絶対に正しいはず」という過信も捨てよう。
念のため最重要セクタにもう一度アクセスしておく。
「再度書き換えられたら」 >>748
『念のため最重要セクタにもう一度アクセスしておく。
「再度書き換えられたら」』
ってのが意味わからんのだがこれ他人説明するための日本語の文法としてあってる？
自身はちゃんと「自分は絶対に正しいはず」といつ過信を捨てられてる？ >>741
「複雑なアクセス」とかよくアクセスって言ってるけど
この場合に考慮が必要なのは書き込みだけで読み込みはどうでも良いよな？ >>741
吐き出したバンドが再度書き換えられたらまた吐き出さなくてはならない
ってのは当たり前の話だと思うのだがその当たり前をなんとかしたいと？
というか既になんとかしてるはずって話か
MCが溢れる時ってのは数千回以上の瓦書きのタスクが積まれてる状態で
そこから数回か数十回程度管理領域の瓦書きタスクを間引けたところで
焼け石に水だと思うけど
何のコストも払わずに出来るならやってるだろうけど SMRは速度低下が起こった時点で無期限保証が適用され
いつでも返品交換できるようにしなければならない
そうしなければHDDメーカーは詐欺集団とみなす！（ｷﾗｯ
そしたら、フラグメントが発生するような使い方をメーカーが禁止するだけ
使い方が悪ければ保証対象外
空き領域のフラグメントが何十個以内までであれば速度保証するが、それ以上であれば保証なしとか
ひとつのファイルのサイズも一定サイズ以下は無保証とか
>>755
良いんじゃね？
どーゆー使い方がダメなのかメーカーが明言してくれるって事で、双方幸せになれるわw フラグメントがーってこのスレでよく見るけどフラグメントの影響による
SMRの動作低下報告なんてあったっけ？
SMRの動作低下って >>238 みたいな初めに大量コピーした時しか聞いた事ないけど
いやどっちかっていうとMC使ってる副産物でフラグメントが多い環境では
CMRより書き込みの調子が良くなるんじゃないかと >>752
ファイルが内部分節化されて例えば断片数3万個の2GBのファイルみたいに
フラグメントのおにぎり状態の場合、そのファイルを読み出す速度は無断片の
ファイルと比較すると10倍以上遅くなるみたいだね。実体験的に。
無断片なら120、断片文節ファイルは20以下。CMRもSMRも同様。 >>758
まあ、フラグメントが悪さしてMCをオバーフローさせて超低速モードに落とし込む。
ということは経験的に何度もはあったよ。合計で数十MB/sで常時複数のストリーミングな
データファイル生成をアプリがファイルをクローズオープンを繰り返ししながら書き込み
続けるような場合。
ただし、フラグメントというのは原理的にOSが醸し出すOS固有の幻想状態の一種であって
HDD自身がフラグメントを生成するわけじゃないからね。OSなりその配下で走るアプリが
無フラグメントを配慮した構成構造動作をするなら速度低下というような問題を起こし難く
することは可能だろうな。>>248のような極小ファイルの超大量コピーという用例の場合
コピーアプリが100MB以上の大きなアーカイブ状にまとめてデータ部分をシーケンシャルに
一括転送した後ディレクトリ情報などをまとめて一括更新するような仕組みがあればいいと思うよ。
ただ、そういうコピーツールがあんまり無い。というか俺は知らないな。エクスプローラの弱点は
大量一括コピーでも実際は一個一個、逐一コピーしかできない。という点だろうね。 >>760 のようなHDDの処理速度の超低下をSMR HDDで何度も経験したので以下のような扱いを導入しトラブルを回避できた。
① Cドライブ上ではデータ保存などは行わない。SSDは256GBで十分。
データ処理HDDが100使用中のようなビジー状態でも、かな漢字変換ができなくなる
といった実用上のトラブルを回避することができた。
②ストリーミング受信はCMRなHDDで行う。速度頭打ちはあるが超低速化は無くなった。
③データ編集後、保存すべきファイルはSMRなHDDにエクスプローラでコピーして倉庫保存する。 100 → 100%
エクスプローラの逐一コピー方式は欠点の一つだろうと思うけれど
長所はコピーされたファイルにフラグメントはまず生じない。という脱断片機能。
フラグメント洗浄機能があることだな。経験的にいえば、8TBのHDDでエクスプローラで
コピーを行なってなおフラグメントを生成したケースは残りエリアが40GBを切ったときだけ。
デフラグするならエクスプローラがおススメ。いったん別ドライブへ一括コピーし、
元ファイルを全削除したのちコピーバックする。これがデフラグを行う最良の方法だと思うなあ。
このコピー&コピーバックをフラグメント存在ファイル限定で行えたら最良のデフラガーになるかも。
>>763
ディレクトリの断片化はエクスプローラーでも発生するよ
倉庫HDDはフラグメント０まで拘りたいのでデータが溜まるつどに数ヶ月ごとにHDD全領域デフラグしてる 最高のデフラグソフトはUltimateDefrag、無料版で充分
>>749
悪い。
でも、それなりに考察はできるようなのでいきなり無下に扱うのもかわいそうかなと。
あと、レス単体あるいは部分的には合っていることも多く、
まるで反論にはなっていなくても（こればっかな気がするがｗ）
反論のようには見えるので、あまりわかっていない人が混乱するリスクが高く、
放置できないってのもある。
ホント、やっかいな存在だよ……。 >>751
正攻法で無理ならとネタに走ってみたが無駄だったか。
あんた５ちゃん向きじゃないな。議論向きでもない。
もしかしたら考察自体向いてないのかもしれない。
最後の返しは予想通り。
だが、今までのやり取りの中で
あなたの知らないことや思い付かないことをこちらはいくつも出してきただろ？
また、あなたの考えのおかしなところを指摘し、いくつかはそちらも納得したはずだ。
今までのパターンから考えて、納得できないのに反論してこないとは思えないからなｗ
少しはリスペクトしてくれ。
念のためだが、自身への過信なんてものはないので、
あなたの反論は毎回注意深く考察してるぞ。
もしかしたら自分には気付かなかった何かがあるかもしれないと。
まあ、残念ながら今まで何ひとつなかったが。
何もないところに何かがあるかもしれないと考えるのはものすごい大変なんだが、
多分あなたにはわからんだろうな……。
ただ、あなたに説明する過程で自ら気付いたことはあるので無駄ではなかった。
ここはわかる人向けに書くのでわからないなら無視してくれていいが、
SMR の挙動を仮想記憶のスワップの裏返しと考えると色々見えてくる。
メディアキャッシュをメインメモリ、瓦領域をスワップ領域とすると、
瓦への吐き出しは積極的なクリーニングそのもの。 リスペクトの心がまるでないことがはっきりしたので、これからは少々乱暴にいくぞ。
>>752
はあ？
読み込みアクセスでも、その間吐き出し作業ができないんだからどうでもいいわけないだろ。
そんなこともわからないのか？
あと、今回は関係ないが、どこが管理情報なのか識別するヒントにはなる。
書き込みほど重要ではないので優先順位付けへの重みは下げたほうがいいとは思うが。
>>753
なんの工夫もなければ数十回程度では済まない可能性があることがまだわからないのか？
まさかシーゲートの中の人もそんなようないい加減な考えで対策しないから
何世代も改良したとか言っておきながらいつまでもごらんの有様なんじゃないだろうなあ。
流石にそこまで間抜けじゃないかｗ
>>758
考察しようとするだけ推測不要論な人よりマシと思ってたが、
結局報告がないと信用しないのかよ。がっかりだわ。
メディアキャッシュに頼れるうちは CMR より良好だろうが
（実際にベンチのランダムライトの結果はいい）、
それを超えたら大変なことになるのは明らかだろうが。
極端な例とはいえ >>720 みたいな考察もあったんだし、
よく見かけ、誰も反論してないなら、少しは信用しろ。 >>757
まずは SMR であることを明言してくれないとなｗ
つか、それをやってくれればかなりの人が納得すると思うけどね。
あとは価格にもある程度還元してくれれば。
開発費のこともあるしせっかくの利幅稼ぎのチャンスなんだし全部還元しろとは言わないが。 >>760
＞合計で数十MB/sで常時複数のストリーミングな
＞データファイル生成をアプリがファイルをクローズオープンを繰り返ししながら書き込み
＞続けるような場合。
事前確保しないだけでもひどい断片化が発生するのに
（SMR への書き込み自体はまとめて処理されるかもしれないが、
のちのファイル削除で空き領域の断片化につながる）、
管理情報アクセス大量発生で SMR いじめだなｗ
つか、使ってるニコ生録画ソフトがまさにその動作かも……。
＞コピーアプリが100MB以上の大きなアーカイブ状にまとめてデータ部分をシーケンシャルに
＞一括転送した後ディレクトリ情報などをまとめて一括更新するような仕組みがあればいいと思うよ。
残念ながらそれは無理っぽい。
まとめて転送するまではいいが、複数のファイルに分割する方法がなさそう。
OS 側の手助けがなければ……って、それなら SMR に優しいアクセスすればいいか。
まあ、SMR と表明してくれないんじゃ対応しようがないけどー。
ちょっと違うが、Fire File Copy にディレクトリエントリを事前作成することにより
ディレクトリの断片化を防ぐ機能があるので多少はマシかも。
管理情報書き換えが増える分余計ひどくなるだけかもしれんがｗ >>763
エクスプローラでなくてもまともなコピーツールなら大丈夫だよ。
コピー用 API を使うなり自前で事前領域確保するなりで、
結局は OS のクラスタ割り当てアルゴリズムにより可能な限り断片化は発生しない。
断片化したものだけデフラグするソフトも色々あるよ。
ただ、これをやり過ぎると必然的に空き領域の断片化が進むという諸刃の剣。
むしろ、断片化していないものを分解してでも空き領域の断片化をなくす
Defraggler の「空き領域のデフラグ（断片化を許容）」みたいなのが
SMR にとって最良のデフラグな気がする。
動作原理的にも実行時のクラスタマップを見ても
ランダムリードで集めたブロックを外周側の隙間から順に埋めているだけっぽいので、
SMR への負担もそうなく現実的な時間で終わると思う。
>>765
こりゃまた懐かしいのが出てきたな。
自分は O&O 派だったが、無料で似たようなことができるということで
有料は嫌という人にお勧めしてたわ。
ただ、どちらも多少無茶をしてでも完璧を目指す方向性のソフトなので
SMR にはちょっと……。 >>770
>>まとめて転送するまではいいが、複数のファイルに分割する方法がなさそう。
>>OS 側の手助けがなければ……
linuxの側にはntfs3Gというntfsな外付けHDDとかをlinux にマウントしてR&Wできるエミュが
あったりする。要はHDDの管理エリアをOSを介さずあたかもWindowsOSが振る舞うように
管理エリアを書き換えればよいわけです。デフラグ系のアプリはそんなことを少しだけ
やっているはず。ファイルのセクタチェインの書き換えとかね。
ntfs 3Gでもntfsのジャーナルはうまくエミュできていないとか。こういうことの一切合切は
MSならきっちりできるよね。仕様がそうなっていないだけで。 RX470＠8GBが爆安だったので、RYZEN5 2600 でXbox play anywhere 対応の
ゲーミングpcみたいな自作機を昨日組み上げた。ドラクエベンチが18450程度。
最近のマザボはm2なSSDをオンボで抱けるのね。512GBのSSDが6000円台。
HDDいらないじゃん。場所無いじゃんみたいな。SSDの原料たるNANDが大きく
値崩れしてるし。HDDメーカー各社生き残っていけるのか他人事ながら心配してしまう。
>>768
まあ、落ち着け。「少々乱暴にいくぞ」とか「はあ？」とか
なんかちょいちょい煽ったりする文章は
正しい情報を得るのに必要？
それ言ってなんかメリットある？
ただでさえレス延ばしがちなんだからなるべく余計なものは控えようよ >>768
「どこが管理情報なのか識別するヒントにはなる」
ってそもそもHDDは管理情報の場所を意識してはならない
設計思想な気がするんだよね
HDDの上でosが勝手にfs作って使ってるだけなので >>767
しょうがない、そこまで言うならリスペクトしてやるかって言うのも違くね？w >>768
アクセス解析って何の問題を解決するためにやるんだ >>768
アクセス解析ってどうやって実現するんだ？
不揮発領域には書き込むのか？ 同じ書き込みに連続でレス付けるようなことしてる時点で
相手の書き込みをよく読んで理解しようとしてない証拠だな。
思いつくままに脊髄反射レスしてるようにしか見えん。
議論ではなく自己主張のし合いでしかない
>>781
いや議題として別々になるものはレス番を分けた方が混乱はしにくいでしょ
1つのレスで複数の物事に返信しようとして
何に対して返信してるのかわからなくなるのはよくある話かなと >>782
そーゆー意見もわかるが、外野からみるとやり過ぎにしか見えん >>773
9x 系まではデフラグソフトが直接管理情報を書き換えてたっぽいけど、
ファイルシステムが仮想記憶やシステムキャッシュと密な関係にある今の Win では不可能。
用意されたデフラグ用 API を使うしかない。
↑を使ってるので安心とうたってるデフラグソフトがあるけど何言ってんだって感じｗ
読むだけなら問題ないので $MFT を直接解析することで素早く分析してるものはある。
オフライン状態にすれば理論上なんでも可能だけど、
本格的にやってるのは PerfectDisk くらいじゃないかな。
こいつはほかのソフトができない（デフラグ用 API が対応してない）
FAT 系でのディレクトリのデフラグが可能だったので、
新しいのが出るたび試用期間中にやってたｗ
まあ、FAT 系のサポート打ち切っちゃったんだけどね……。
ほかのソフトにもあるブートタイムデフラグは、同様にやってるのか
単にロックされる前に API を使ってるのかはちょっとわからない。
話を戻すと、デフラグ用 API は
「対象のここからここまでをこのクラスタからの連続領域に移動」
ってことしかできないようなので、ファイル分割に応用するのは無理そう。 >>775
お前の行動パターンが読めないので色々試してるんだよ。
強く言われることにより、考え直したり勝機がないことを悟っておとなしくなる奴もいるからな。
切れて暴れる奴もいるが、>>766 の解消にはつながる。
まあ、今は運営に期待できないのでスレが機能しなくなる程だと困ったことになるが、
流石にそこまでのキではないと信じてる。
>>776
気のせいです。最終行は前半の考えを肯定することにはなりません。
>>777
推測に限らずひとりの力でやれることには限界があります。
他者をリスペクトできないあなたの成長は遅れることでしょう。
今までそれを続けてきたのでこの有様である可能性が高そうです。
>>778-779
何回も言ってるので読み直してください。
不揮発領域に保存するかについては、必須ではありませんが、有用ですし、
必須情報書き換えのついでに行えばコストは無視できるので恐らくやってると思われます。 >>785
「何回も言ってるので読み直してください」
それだけは無くね？
俺以外の奴からもほのめかし君って言われてるし
まあ具体的な目的とか方法論は無さそうだとは思ってたけど
やっぱそれが無いと文字通り話にならんと思う >>785
>>742 辺りにぐだぐた書いてるみたいだけど結局解決すべき（している？）問題はなんなんだと 俺はO&Oよりも絶対的にUltimateDefrag派
ちまちま作業すればセクタ単位でファイルを自在に配置できるんだぜ
>>787
まずアクセス解析しないと問題が発生するからアクセス解析してるんでしょ
その問題はなんなんだと >>785
「勝機が無い事を悟って大人しくなる」
これ言ったら駄目な奴でしょw
自分は絶対に正しいはずと考えてる人の発想じゃねーかw
違うでしょ、勝ち負けなんてないの
正しいものは正しい、それだけ >>785
アクセス解析によって改善出来る問題について気になるのは
百や千のファイル書き込み程度だったら管理領域含めてもMCは溢れないだろうから
アクセス解析が有効なのは万単位の書き込みじゃないかと思うのだが
そうなるとまずそんなに書かないライトユーザーだと全く不要だと言う事
で、万単位で書き込む場合もよくあるケースは >>236 みたいに
購入後直ぐに古いデータを移行する時で
この場合だとアクセス解析も何も MC に乗ってるのがほぼ全てなので
この場合も殆ど意味無い
なので何の問題を改善するためにアクセス解析をするのか
してるのかわからないという話 SMRは使う度にクイックフォーマットが基本とか言い出したりして。そうじゃなかったら終わるまでひたすら待て！とかイキったり。
ほんと最初のデータ移行対策をがっちりやれば悪評の半分以上は解消するだろうにな
なんでそれやらないんだか メーカーの怠慢と言われても仕方ないだろう
>>793
その通りではあるが如何せんファイルの書き込み先アドレスを決めるのはosだからな
HDDやアプリではどうにもならないんだろうなとも思う とりあえずマイクロソフトに金積んでなるべくシーケンシャルに書くモードでも
作って貰えば解消するかもね
自分は倉庫用ＨＤＤを買ってきたら、初期不良検査の後、TrueCryptでパーティション暗号化の初期化をして、
その後サイズ０のダミーファイルを数十～数百万個作成してMTF予めを充分に肥大させておいてから、
次にfsutil file createnewコマンドのバッチファイルで１ＧＢきっかりののスパースファイル容量いっぱいまで作成して領域確保しておく。
（正確にはUltimateDefragを利用してセクタ単位までばっちり管理できるようにダミーのスパースファイルを配置しておく）
そのＨＤＤへ倉庫送りのデータを移動するときには必要な分だけ、領域確保しておいたダミーのスパースファイルを削除して、
書き込まれるディスク上の位置を管理している。
移動前に削除する領域はディスクの後方、フラグメントが発生したら、ディスク前方の確保領域のダミースパースファイルを削除して、
UltimateDefragで前方送りのデフラグを行なわせる。前方送りの処理だけなので、デフラグ時間は比較的短時間で済む。
このようにしてフラグメントのないように、倉庫ファイルを管理している。
フラグメントを無くすことで、ファイルシステムが壊れたときの復旧がしやすくなるという効能も狙っている。
訂正
自分は倉庫用ＨＤＤを買ってきたら、初期不良検査の後、TrueCryptでパーティション暗号化の初期化をして、
その後サイズ０のダミーファイルを数十～数百万個作成してMＦＴを予め充分に肥大させておいてから、
次にfsutil file createnewコマンドのバッチファイルで１ＧＢきっかりののスパースファイル$0000、$0001、,$3456,、,、を容量いっぱいまで大量に作成して領域確保しておく。
（正確にはUltimateDefragを利用してクラスタ単位までばっちり管理できるようにダミーのスパースファイルを配置しておく）
そのＨＤＤへ倉庫送りのデータを移動するときには必要な分だけ、領域確保しておいたダミーのスパースファイル群を削除して、
書き込まれるディスク上の位置を管理している。
移動前に削除する領域はディスクの後方、適度にフラグメントが発生してきら、ディスク前方の確保領域のダミースパースファイルを削除して、
UltimateDefragで前方送りのデフラグを行なわせる。ディスク後方から前方送りの処理だけなので、デフラグ時間は比較的短時間で済む。
(ファイル名順に並び替えるなどするのもこのとき)
このようにしてフラグメントのないように、倉庫ファイルを管理している。
フラグメントを無くすことで、ファイルシステムが壊れたときの復旧がしやすくなるという効能も狙っている。
さらに訂正
自分は150円セールの時にLサイズマックフライポテトを50個買ってきたら、不良芋検査の後、HEALSIOでオーブン加熱の再調理をして、
その後サイズLの長いポテトを数～数十本選別してLサイズを予め充分に確保しておいてから、
次にPhilips Nonfryerのローストフライで10cmきっかりのポテトフライ\10円分、\100円分、\300円分と小容量で大量に冷凍して夜食確保しておく。
（正確にはPanasonic partial freezingを利用して芋の細胞までばっちり温度管理できるようにタッパーを配置しておく）
その冷凍庫の非常食倉庫送りのポテトを消費するときには必要な分だけ、非常食確保しておいたローリングストックのポテト群を消費して、
飲み込むポテトの量を管理している。
食事前に消費する本数はフリーザーの後方、温度上昇が発生するから、フリーザー前方の確保領域のポテトと先入先出法で入れ替えて、
Panasonic partial freezingで前方のパーシャル冷凍を行なわせる。フリーザー後方から前方送りの処理だけなので、フリージング時間は比較的短時間で済む。
(夏場に並び替えるなどするのはこれがいい)
このようにしてポテト不足のないように、備蓄ポテトを管理している。
ポテトが無くなることで、備蓄が失われたときの絶望感が和らぎやすくなるという効能も狙っている。
>>799
こんな時間に食べたくなっちゃったじゃないか
最寄りのマック24Hじゃない
責任とって >>800
だから、そんなときのためにマクドポテトを備蓄しておけって話だろ >>786
あなたは気付いていない（気付けない）のかもしれませんが、
掲示板という場においてほかの方々に迷惑をかけるレベルでこれまで色々説明してきました。
ある程度の知識と読解力があれば伝わりそうなことが伝わらないので、
同じことを言葉を変えて何度も繰り返したりもしました。
あなたの発言はそれっぽく見えることもあるので存在としてやっかいでしたが、
おおむね……だと周知されたでしょうからそろそろ特別サービスは終了します。
あ、「ほのめかし」というのは技術面のことではないと思いますよ。
どちらかといえばうざがられるレベルで具体的に語るの好きですから。
>>790
初めから自分が正しいはずと考えるのは危険ですが、
ある程度やり取りを続ければほぼ間違いないだろうと確信に至ることはあるのです。
前にも言いましたが、私は必要以上に相手が正しいかもしれないと考えるタイプです。
>>791
使い方や状態によっては問題が発覚しないことなど誰でも知っています。
が、現に問題になることもあるのですから、工夫する意味はあります。
あなたの薄い考察で意味がなさそうと考えることこそ何の意味もありません。
いいから、ぐだぐだ言わず読み直してください。 >>798
楽しそうなことやってるなあｗ
$MFT::BITMAP はどうしてる？
XP 時代はオンラインデフラグできなかったので邪魔でしょうがなかったものの
$MFT 自体はなるべく大きくしたくなかったので、
管理領域いじって $MFT::BITMAP だけ無理やり拡張してたわｗ
あ、createnew で作られるのはスパースファイルじゃないよ。
スパースはファイル長として論理的に存在しながらクラスタには割り当てないこと。
UsrJrnl とかで使われてる。
そういや、こいつも SMR の敵だな。意味がわかるなら無効にしてみるのもいいかも。
ただ、createnew で作ったばかりのファイルもまた特殊で、
クラスタが割り当てられているにも関わらずスパース同様ゼロを返すようになっている。
知ってそうだけど、デフラグすると瞬間移動して面白いよね。 >>803
$MFT::BITMAPが目に付くようになってきたら、別のドライブを用意して最初からぜんぶやり直し
大量のファイルを流し込んだときなど$MFT::BITMAPがいくつも発生して目論見を邪魔するが、発生する条件と解消する方法を知らないのでどうしようもない スパースファイルで指摘があったので再訂正
自分は倉庫用ＨＤＤを買ってきたら、初期不良検査の後、TrueCryptでパーティション暗号化の初期化をして、
その後サイズ０のダミーファイルを数十～数百万個作成してMＦＴを予め充分に肥大させておいて（このときの膨大なダミーファイルはすくに削除）から、
次にfsutil file createnewコマンドのバッチファイルで１ＧＢきっかりののスパースファイル$0000、$0001、,$3456,、,、を容量いっぱいまで大量に作成して領域確保しておく。
（正確にはUltimateDefragを利用してクラスタ単位までばっちり管理できるようにダミーファイルを配置しておく。
また、fsutil file createnewコマンドはNTFSにおいては領域を確保するだけで実データはディスクに書き込まないのでこの工程は大容量ドライブでもものの数分で済む。）
そのＨＤＤへ倉庫送りのデータを移動するときには必要な分だけ、領域確保しておいたダミーファイル群を削除して、書き込まれるディスク上の位置を管理している。
移動前にダミーファイルを削除する領域はディスクの後方。倉庫送りで移動してきたデータファイル群が適度に溜まり、適度にフラグメントが発生してきら、
ディスク前方の確保領域のダミーファイル群を適切な分量削除して、UltimateDefragで前方送りのデフラグを行なわせる。
ディスク後方から前方送りの処理だけなので、デフラグ時間は比較的短時間で済む。(ファイル名順に並び替えるなどするのもこのとき)
このようにしてフラグメントのないように、倉庫ファイルを管理している。
フラグメントを無くすことで、ファイルシステムが壊れたときのファイル救出がしやすくなるという効能も狙っている。
>>802
いや単純になんで質問に答えられないんだ？という疑問が
一応質問はアクセス解析する目的は何って事なんだけど？
なんか色々良いことがあるらしいのはわかってるから主目的はなんなんだと
いや、暇があったら読み返して見るけど俺の読解力だからな
また見当違いな質問が大量に出る可能性が高いと思わないか？
ここらで1つキッチリまとまったアクセス解析をする目的のレスを書いてみないか？ >>802
現に問題になる事もあるって
そのSMRで1番よく起こる致命的な問題パターンが購入直後の書き込みだって事はわかりきってるのに
そこに効果の無いアクセス解析に注力するってのがわからない >>806
主目的は無駄な瓦書き換えをさけることです。
しかしこれからどのようなアクセスが来るのかわかりませんので、
過去のアクセスパターンから予測するしかないのです。
>>808
断片化が進んだ場合にも致命的な問題は起こり得ます。
むしろこちらこそ原理的に回避不可能であり、
まっさら状態のほうは大きく改善できる可能性が残されています。
また、まっさら状態であろうと、場合によってはアクセス解析しないと大変なことになります。
このように、あなたの考察は薄っぺらいのです。
そのことを自覚しない限り正解に近付くことはないでしょう。 >>804
$MFT::$BITMAP（前回 $ がひとつ足りなかった）は
$MFT 内のレコードの使用状況をビットマップにしたもの。
レコードは基本的にはファイルやディレクトリひとつにつきひとつ使うので、
つまり 4KB クラスタなら 32768 個ファイル等を増やすごとに１クラスタ伸びる。
あなたのやり方の場合、$MFT を肥大させる段階ですでに伸び切ってるはず。
サイズ０のファイルなら（Vista のエクスプローラでない限り）クラスタは割り当てられないので、
UsrJrnl に邪魔される可能性があるくらいであまり散らばらないのかな？
$MFT を肥大させておいた以上にファイルを追加すれば当然ばらばらに散らばる。
実はとりあえず Win10 なら標準デフラグでデフラグ可能。
API 的には Win7 の時点で対応済みなのは確認してるが（Vista は不明）、
Win10 より前の標準デフラグが対応してるかは未確認なので試してみて欲しい。
駄目ならブートタイムデフラグしかないが、
あなたが解消方法を知らないということは UltimateDefrag は未対応なのかな……。 CMR 4TB → SMR 4TB
SMR 4TB → CMR 4TB
それぞれ3TB前後のファイルコピーして時間計ったけど駄目だなあ
１ＴＢとか２ＴＢのＣＭＲドライブをテンポラリ保存ストレージにして、溜まってきたら整理して４ＴＢとか８ＴＢのＳＭＲドライブに移動して長期保管
そういう使い方向けのドライブだよ
>>809
断片化が進んだ時の問題がなんで原理的に回避不可能なんだ？？
デフラグすれば良いでしょ？？
何のためのデフラグなんだ？？ >>815
いや、少しは流れ追ってよ。
断片化が進んでいることが原因での速度低下は工夫ではどうにもならないって話なのに、
デフラグで状態変えちゃったら意味ないでしょｗ >>817
本気で言ってるのか？？？
SMRのユーザーは断片化が進んでる事が原因の速度低下はデフラグで回避出来ないのか？
CMRのユーザーは断片化が進んでる事が原因の速度低下はデフラグで回避出来たと思うが SMRでデフラグしたら内部は凄まじいことになりそうだ。
SMRで論理アドレスと物理アドレスが完全分離されよりカオスな状況に・・・
CPUコア４つ積んでいるSSDのコントローラのように賢くないだろうしなあ・・・
どうするんだろうねえ・・・コマッタコマッタ・・・・
>>818
昔からある断片化はCMR/SMRどっちでも本来の意味のデフラグで改善可能。
瓦ブロックと言う意味での断片化は、SMR固有でソフトでは改善不可能(構成を知らないから)。ファームは構成を知ってるんだからWD方式なら出来るかな(やってるとは言ってない)。
と言う意味だと普通に考えると思うが違うのか？ >>819
時間がＣＭＲの理屈上2倍～数倍程度の時間が掛かるだけでデフラグ自体は問題ないよ まとまった空き領域が広いほどデフラグは早く済む
ＳＭＲのデフラグの速度では特にそれが影響する
なのでＨＤＤ購入したら最初に、のちのデフラグを行なうための領域を確保しておくのがコツ
前方送りのデフラグなら、ＣＭＲの場合と同じ、ディスク内コピー（移動）と同じ、デフラグ元読み込み→デフラグ先書き込み、の1倍速でのデフラグで済む
どんなに空き容量あってもメディアキャッシュの容量は固定値
そもそもデータ倉庫にするのにデフラグなど不要
SMRはシステムで使う様な物じゃない
倉庫ディスクをのフラグメントを無くしておくことは、ファイルシステムの異常時にファイルの救出をしやくすなる効果を狙っている
>>822
デフラグしてセクタ単位でファイルデータを綺麗に並べられても
瓦ブロック、バンド的には断片化されたままとかそんな理屈？
いやバンドだってセクタが並んだものを区切ったものだからセクタ単位で
断片化してなければバンドでも断片化してないと思うんだけどね 残り容量の断片を無数のＳＭＲブロックに分散させないことが大事
残りよう容量をできるだけ一まとまりに集めることが大事
たとえば、3TBSMRドライブが残量約372GBを残してほぼいっぱいになっていて
残量約372GBのすべてのクラスタ（4KBで計算）が約95000個のSMRブロック（ひとつのSMRブロックが平均で30MBとして計算)に分散している最悪のケースの場合、
残量約372GBを埋めて書き込むのに3TBのすべてのSMRブロックを書き換えなくてはならないのである
100MB/sで読み書きできる環境だとしても、空領域である372GBを埋めて書き込む（全部SMRブロックを書き換える）のに約16時間、実態として良くても5.6MB/sという低速での書き込みになるのだ
BSデジタル放送のビットレート最大24Mbps(4MB/s)と、地上デジタル放送最大17Mbps(2MB/s強)の番組を放送画質そのままで録画しようとした場合、
SMRドライブでは上記のように、最悪の場合で理屈上は5,6MB/sの速度なので、
リアルタイム録画１ｃｈ分であればどうにかSMRドライブにリアルタイム録画できるかどうかということが分かる
>>818
「断片化が進んでいることが原因」での速度低下は「そのままの状態では」どうにもならない。
これだけだとへ理屈っぽいが、流れを追えばそうではないとわかるはず。
>>822
いや、そんな高レベルなことではなく、>>808 が
＞そのSMRで1番よく起こる致命的な問題パターンが購入直後の書き込みだって事はわかりきってるのに
とかおかしなこと言ってるので、断片化の問題こそ致命的だろうってな話。
これ、勝手に大量書き込みを前提にしてるんだろうけど、
誰もがするわけではなく、やったとしても速度低下しないケースもあり、
なんにせよ同じ作業ならまっさらより断片化しているほうが問題は起きやすいんだし、
何から何まで滅茶苦茶だよなｗ アドレス変換方式によるデフラグの効能については、
変換なしなら、もちろん CMR 同様に効果大、
バンド単位変換でも、空き領域の断片化とバンド内での断片化の解消は大いに効果あり、
セクタ単位変換では、ガベージコレクションが促進される副作用があるくらいでほぼ意味なし、
ってとこかな。
>>825
部分的に更新や削除するような使い方でも更新日時順でソートしとけば良さそうだね。
別のところからコピーしてくる倉庫的な使い方の場合、
自分のように作成日時も保持してコピーしたい派だと駄目だが、
エクスプローラを使う人なら作成日時順やアクセス日時順がよいかも。
ちなみに、最近の Win は効率のためファイルのアクセス日時は更新しないので
（旧来動作に戻すことは可能）、真の意味でのファイル作成日時として使える。
エクスプローラも移動の場合には作成日時を保持するので微妙に違う。
SMR は基本的にはデフラグ苦手だけど、
断片化がひどくなってから使うのではなく、
常に完全な状態を保つような使い方は案外 SMR 向きかもしれないね。
ただ、デフラグツールが頻繁に実行するのをお勧めするような最適化方法は、
SMR にとって大敵な空き領域の断片化を促進してしまいがちなのがちとネックだが。 CMRに詳しい人に尋ねたいのだが CMRなHDDってR/Wともに
トラック（シリンダー）単位で一括読み書きするんじゃないのかな？
大昔のST-506なHDDではセクタbyセクタで読み書きしていたので
スキュー値でセクタ間の飛び数を調整してCPUの処理速度に最適化してたけど
CMRもシリンダ一括ならデフラグ時の煩雑さはSMRと大して変わらないんじゃない？
>>835
少なくとも書き込みはそんなことしてない。リードモディファイライトが必要になってしまう。
もしやってたなら AFT 問題はなかった。
もちろん、バッファに１トラック分集まり結果的に一括書き込みになることはある。
読み込みは、ほかに読まなければならないものがなく、バッファが空いてるなら、
トラック終了まで（あるいはそれ以上）ついでに読んでるかもしれない。
連続アドレスで読み込みが続けばもうけもの、そうでなければ捨てればいい。 これだけHDDのSMR化が進むということは
システムはSSDに データファイルはHDDに
役割分担を想定してラインアップしているんでしょうなあ
HDDメーカーは当然のようにSSDラインナップしているわけですし
ファイル分断化が進んでアドレステーブルがカオスったHDDは
二つ用意して定期的にセキュアイレース＋ピンポンコピーすりゃいいんじゃねえの？
バッチで組めば問題ないだろ
>>835
今時の高密度HDDで表裏のトラックを一致させるのは無理
しかもヘッドにも個体差があるので表裏で記録密度すら微妙に異なる
なのでアクセスはセクタ単位で行うし、
読み書き回路も一つしかないなのでヘッドも一つしか同時に使えない
シーケンシャルでLBA順繰りにアクセスすると実際の動きは、
しばらく1枚目表→しばらく1枚目裏→しばらく2枚目表→しばらく2枚目裏→みたいな感じになる >>832
いや屁理屈でも何でもなく >809 で断片化による速度低下は原理的に回避不能って言うから
そんなものは古来よりデフラグという手段で回避出来るようになってるでしょうと
「そのままの状態では」ってそんな個人的な縛りを主張されても
「そのままの状態」で回避出来るようにする必要性がわからないので
デフラグで回避出来るものは出来るとしか言いようが無い
デフラグという回避手段が気に食わないのはわからないではないが
昔からWindowsではそういう運用になってるから今更言われてもなと
勝手に大量書き込み前提というかMCが20GB以上乗ってるという情報がある以上
SMRとしてはそれ以上のランダムライトが無いと溢れようがないわけで
それを大量書き込みとは限らないと言われても
20GB以上のランダムライトが発生する運用なんて一般的にはあまり聞かないし くっそ、ワッチョイの UA 部分が同じなので怪しいとは思いつつも
流石に >>815 みたいな返しはしないだろうから横レスかと思ったらまさかの本人だったとは。
文盲だか論理が壊れてるんだか知らんがこいつの滅茶苦茶さを甘く見てたわ。
まあ、ＡＩ風喋りも飽きてきてたしもういいか。
さよなら。 >>841
普通デフラグ完了したら空き部分もシーケンシャルに纏められるでしょ >>842
Windows標準のデフラグはそんな気の利くことはしてくれない
perfectdiskとかのきっちり前詰めしてくれるソフトでないと >>844
きっちりやりたければそういうの使えば良いと思うけど
この場合大抵の人の書き込み時の断片化ファイルがMCの20GB超えない程度
であれば良いのでハードルは低いかなと
まず20GB一気に書かないと超えないだろうしね >>845
何故ファイル断片化の話に戻るのですか？
ﾜｯﾁｮｲ 9387-eGkX さんが気にし話の流れになっていた事は、空きが減った時・MC空きの断片化が進んだ時の話で、結論はボボ(細かい事の思考実験はしてない) >>833 だと思うけど？
相変わらずﾜﾁｮｲのホスト部同じだし、私もソロソロ止めますわ >>846
MCが溢れる可能性があるのは断片化したファイルを書き込む時だから
SMRの瓦部分の空きが断片化した結果
OSが断片化したファイルの書き込みををSMRに依頼する事になってMCが溢れるって話なので
そんなに食い違った話では無いかと >>809
まっさらな状態の方は大きく改善可能と言ってもSMRが出てもう何年も経つのに
未だに全然出来てないから >>238 みたいな人が出てきてしまうわけで
これが正に回避不能な状態では無いかと
これが断片化に起因するものであればまだデフラグという策は残されていたと思うけど ホストからの書き込み命令や読み出し命令のスループットに対し
ディスクのシークスピードの方が遥かに遅いのに
瓦の都合によるMCなどという余計な記憶領域が追加され
あまっさえMC←→瓦の間でホストと関係の無いディスクアクセスが発生するのだから
そりゃホストの命令は待たされまくることになるだろう
これが逆 すなわちホストからの書き込み命令や読み出し命令のスループットに対し
ディスクのシークスピードの方が遥かに速かったら問題なかったのだ
>>844
PerfectDisk は実は細かい隙間は無視する仕様。
一応きっちり詰めるオプションはあるが、SMART Placement の設定の中にあるので
「空き領域の結合」時には意味がない気がする。あるなら UI の不出来。
ちなみに、↑は Defraggler の「空き領域のデフラグ」みたいなのを連想してしまうが
ファイル等の断片化を解消しつつ詰める普通のデフラグのことで、
「デフラグのみ」は空き領域の断片化を無視するクイックデフラグ的なものなので注意。
SMART Placement が実用的な速度で使えるかにかかってるが、
あまり SMR 向きじゃない気がするなあ……。 >>851
まあ、それは容量アップと引き換えに起き得る犠牲として初めからわかってたこと。
だから別ものとして区別するべきであり、
仕様用途を限定しない通常製品として売るようなものではなかった。
失敗というなら売り方だよね。
でも、多少遅くなることがあるだけでなんとか普通に使えるような工夫は可能。
たとえばメディアキャッシュの空きが減るほど吐き出しの優先度を上げるようにすれば、
いきなり激遅になる可能性はぐんと減る。
これは使用感だけではなく RAID コントローラ等に切り離されてしまうリスクを考えても重要。
あまりひどい報告のない WD は数々の工夫で大きく改善してきたんだと思う。
SMR を出してもう何年も経つのに未だに全然出来てないシーゲートは何やってんだろうね。 これはSMRですよと書いてくれればいいのに。区別出来ないのか糞。こっちはSMRなんて買いたくないんだよ。
>>855
いや瓦書き速度 <<< CMR書き込み速度である以上 MC 溢れは完璧には防げない事は確定してるわけで
そんな中この報告の少なさは上々じゃね？ >>809
あと断片化時のMC溢れをそんなに気にしてるなら瓦直書き判定は >>613 であるはずなんじゃないかと
バンド30MBとして30MBのデータ書く場合に瓦直書きになる期待値は15MBあるし
バンド丸ごとの書き込みしか直書きしない判定だと
30MBのデータ書く時の瓦直書きになる期待値はほぼ0なわけで >>857
このスレを訪れるようなのはSMR避けてるからじゃね？
自主的に人身御供として身銭切るのはアホらしいと >>856
そもそもSMRの存在を知らなければSMRを買いたくないなんて事も思わないわけで
SMRを明記しないメーカーの策略により実際にそんな人がHDDユーザーの大半を占めるという
完璧な商法に我々は成す術が無いw データ復旧業者が直面するSSDのデータ救出困難。スマホはまず不可能、悪徳業者に注意を
https://pc.watch.impress.co.jp/docs/news/1192004.html
＞HDDに関しては、SMR(Shingled Magnetic Recording)技術が使われているものがあり、
＞ガベージコレクション後にブートレコードが移動してしまうことや、従来のCMRのように
＞最終セクタの位置が容易に特定できるように書き込まれず、LBA変換テーブルで記録
＞場所が制御されることなどから、こちらも復旧の難易度が高くなっている。 復旧し辛いというのもSMRを避けたくなる大きな要因なんだな
速度面だけなら我慢すればいいだけだが
倉庫用途としても欠点抱えてるというのが
>>863
それってサルベージ業者の不安煽り&売名セミナーのお話じゃないの？
ガベージコレクションとか具体的にどの機種のお話？なんだろうねえw >>867
2TBからSMRの6TBに移して、ついでに写真も全部バックアップしようかと思ってるんだけどやばいかな？ >LBA変換テーブルで記録 場所が制御されることなどから、こちらも復旧の難易度が高くなっている。
いいことが一つも無いねー君達
そもそも壊れたり消したりした物から読める方がおかしいっていう
>>863
うーん、数年前の記事で将来的にそうなるだろうってのはあったけど、
セクタ単位変換なものがもう普通に市場に出回ってるとしか思えない書き方だなあ。
まあ、ライターがちゃんとわかってない可能性もあるが。
細かいところで怪しい説明がいくつかあるしｗ
セクタ単位変換方式には SMR の弱点を隠す数々のメリットが考えられるものの
説として全力で乗り切れないのは変換テーブルの扱いの難しさ。
最低限必要になる４バイトだとしても 6TB だと 6GB にもなる。
リードアクセスでも必ず必要になるわけで、
よく使う部分を RAM にキャッシュする程度で実用になるとはちょっと思えない。
NAND かなんか使ってる？ 寿命は？
……まあ、SMR だということを隠してるわけだし、
現実的な寿命があったところで驚きはしないが、そんな HDD 嫌だなあ。 >>865
サルベージしづらいのを倉庫用途としての欠点とまで考えていいのかはともかく、
完全に壊れる前の危険を察知する段階でも色々わかりづらそうなのがなあ。
メディアキャッシュが死に掛けの場合にどういう挙動になるのか。
瓦部分の不良セクタはどのような扱いになるのか。SMART にはどう出るのか。
SMART に SMR 特有の項目を作って欲しいところだけど、SMR だということを隠してる（ｒｙ >>872
あの記事の大半はSF的なデタラメでしょ SMR本来の論文から推測される問題点をデータ復旧の点から並べただけの記事でしょう。
HMやDMの違い、メーカーごとのアルゴリズムの違いなどそれぞれの要素にはそれぞれ問題は有る。
何かしら割り切ったうえでデメリットを一部甘受するSMRで、
デメリットだけ並べたらそりゃぁ復旧不能にしか見えんだろう。
というかデータ復旧業者の業界団体が主催って点で
復旧不能な案件に対してのただの逃げ口上でしょ。
>>875
> 何かしら割り切ったうえでデメリットを一部甘受するSMRで、
> デメリットだけ並べたらそりゃぁ復旧不能にしか見えんだろう。
これは同意だな、SMRはユーザーにはデメリットしかないんだよ まあ物理アド=仮想アドと言われてる海門式なら
復旧難易度はCMRと変わらないんじゃないかね
>>868
一度に移動すると途中から猛烈に遅くなる。機器がそれでも大丈夫なら買えば >>872
そもそもHDDは物理的なシーケンシャルアクセスが極めて速いって特徴があって
OSもそれに依存して運用してしまっているのに
HDD側でそれを勝手にセクタ単位で並べ替えてしまったら
パフォーマンス面で間違いなく破綻するっていうね
シーケンシャル関係なく速いSSDとかじゃないと無理だわな >>868
写真の1ファイルのサイズの小さくて全体のサイズが数100GB位大きいと
写真のコピーに数日とかかかるかも知れないが
のんびりコピーで良ければいいんじゃないか
一度コピー出来れば普通に使える
とはいえ >>515 でもコピーが遅くなる事は無かったので
コピーが異常に遅くなる条件にはまだ謎が多いが なんでこいつら復旧業者より上から目線なん?
人としての価値も社会貢献度も技術力も知識も
復旧業者の皆さんの方が数万倍上なんだが。
なんで無記名掲示板でまで不特定の人に媚びへつらおうとするのか
頭下げ続ける事が癖になってるのかな
ここの人が復旧業者より下と何故言い切れるのだろう
自分がそうなのかな
あ＾～SMR開発した奴死なねえかな
開発される前の世界線に行ければ開発を阻止できるんだが
ＳＭＲが存在しないパラレル世界では４ＴＢのＣＭＲがＨＤＤがまだ１万５千円前後
>>881
実務経験のない、頭でっかちばっかりだってことよ。ここの長文連中を見ればわかることだろ。 >>888
いやいや、元記事をよく読んでくださいよ。復旧業者ができるって言ってることのいくつかはウソだってはっきり書いてあるから
あなたがSMRやスマホの高復旧率を謳う業者でしょう。 瓦タイプ
今は要らない
シーケンシャルファイルだし…
なんで復旧業者に上から言えるかって反論してこないからだな
誰かが論破してくれれば大人しくもなるだろうね
瓦は今はいらないというか容量以外はCMRの下位互換でしかないからな
CMRで十分な容量出せれば一生いらんでしょ
>>889
修復出来るのはオントラックとかの世界で数社だろうし料金億ドルどかなんだろうなきっと
一方で某Webメディアで第第的に宣伝記事載せてるところは詐欺で有名だな CMRで1.8TB/プラッタ まで可能なんだよね
SMR2.0/プラッタ なんてはっきり言って存在価値ない
SMRのせいでCMRの高密度品が4TB,6TBに降りてこないし消費者にとって害悪でしかない
今後は
アクセス速度を気にするデータはSSDに
アクセス速度を気にしなくて良いデータはHDDに記憶してね♥
てのがHDDメーカの回答
>>894
そうか、そうとも考えられるな。
まぁでも無条件で悪害でしかないは言い過ぎでしょ。
「SMRのせいでCMRの高密度品が4TB,6TBに降りてこないし、安く(半額程度？)なければ消費者にとって害悪でしかない」 8TBのCMR(東芝)と8TBのSMR（海門）を使ってるけど、
通常使用じゃ体感に大差はないね。
ただ動画関連(特にTS録画)になると差が出る。
具体的には「複数の同時録画時」のディスクアクセスの余裕具合が全然違うね。
SMRは2～3番組を同時に録画中に、そのHDDから別番組を再生しようとすると
読み出しが間に合わずに再生がおかしくなる。
対してCMRだと何事もなく普通に再生できるし、4～5番組録画中に再生しても問題はない。
これはディスクの「複数ファイルの同時書き込み・読み出しの能力の差」がモロに出てるからだろうな。
あと動画再生時のシークの速度がＣＭＲの方が明らかに速くて快適なんだけど、
これは記録方式ではなく回転数の差かもしれない。
結論は「録画ドライブはまだまだ7200rpmのＣＭＲ。ただの保管庫は5400rpmのＳＭＲで十分」となる。
逆にここまでランダムアクセスが欠陥まみれなら大人しく構造上の仕様と認めてテープドライブみたいに手動でリトリーブ出来るツール用意しろよって感じだよな
メーカーが記録形式をきちんと公表して販売しないのが唯一最大の問題
これはCMRこれはSMRと外箱に書いて売るだけでいい
それをしないメーカーまさにゴミ
消費者がCMR希望かSMR希望かきちんと表明して買いに来ないのが最大の問題
俺ははCMRわたしはSMRとおでこに書いて買いに来るだけでいい
それをしない消費者はまさにゴミのようだわはははは
瓦タイプ 255MBずつ
1MB分を削除した場合
空いた分は、そのままにするのか？
やっぱり、詰めのか？
書き込むクラスタ位置はOSのファイルシステムが決める
シーケンシャルファイル(磁気テープ)でも
詰めれるし
差分も出来る
まあ～タイムラグは覚悟する
>>904
このスレの人の常識だとTrim=全消去だというのでWin10とかが正式対応して定期的にTrim発行してくれると面白いですね。 DRAMのイメージだな
メディアキャッシュは瓦最小単位の複数のキャッシュに分割されていてロウアドレスにくくりつけされているイメージ
ロウアドレスのヒット／ミスでキャッシュか瓦かを選択しているんだろう
書き込みは
メディアキャッシュがほぼフルになるまではMC優先かな？
閾値越えたら瓦に移し変えて空きを作る
メディアキャッシュ
CMR型の二次キャッシュ
フロートを超えたら？ どうなる
容量も良く分からない
>>906
まあそうだな
実際HDDのエンドユーザーの99.9%以上がSMRかCMRかなんて気にもしてないだろうからな
使った結果も多くの人には >>898 で言ってる位の比べないとわからない程度の違いしか無いだろうし >>912
ほぼフルというかフルになるまでMC優先でよくね？
どうせフルになったらMC書きを止める処理は必要なんだし
ほぼフルでわざわざ瓦は書き優先にしてホストの処理を遅くするメリットは無いでしょ MCはFIFO構成
書き込みは必ずホスト→MC→瓦
MC→瓦転送はMCの充填率のみに従う
読み出しのときは瓦かキャッシュか選択
これで大量にデータを記録していらいらした後でも
２－３日すれば又アクセス頻度の高いデータはMCに集まる
SSDツールで調べた限りでは５GB／1日以下が平均的な書き込み量
SSDのブロックサイズ（４MB/１T）と瓦ブロックサイズ（２５６M／４T？）の
差を考慮する必要があるが
ホスト←→MC間で完結可能なMC容量はも想像できるのではないか
>>913
パナソニック製レコーダーHDD換装スレで暴れてた高齢ニートかな？
あなたの知識は全部間違いなので出直してください >>917
茂のMTCの動作とはかすりもしない模様
なお、MCとバンドで読み込み速度に差があるという記述はない だからDRAMと同じだってばよ
ちなみにメモリにエラスティックな機能を持たせるのは
非同期通信では常識なのでよろぴく
>>920
MTCがなにか調べてないでしょ？
論外 でも…
パナソニック？
瓦タイプと言ってたやん
アタマ～♪大丈夫？
・低速になる場合がある
・データ復旧が難しい
・そのくせ大して安くない
こんなん誰が買うんだって話
アドレスの再配置？
同時に機能するヘッドが一つしかねーのに無理ゲーでしょ
アドレス管理はホストに任せるべきだな
後でフラグメント破綻するか先に並べ替え処理で破綻するかの違いだけ
どうせ再配置してもフラグメントするしな
瓦を意識したデフラグツールが一番スマートなのではないか
SMRドライブはツール同梱必須だな
はぁ?
「語りたかったら」だと??????
お前らうざがられてる理由、いまだに理解してねぇな。
妄想や推測は妄想や推測だって必ず書けや。
あたかもメーカー仕様や実際にそのような設計であるかのように
長文貼りやがって
正確な技術内容が混乱してこのスレは
全く情報源として無意味になってんだよ。
テメェらのせいでSMRについて
正確な情報を探してる人間がどれだけ迷惑してるか。
前スレで追い出された奴ら、しれっと戻ってきてんじゃねーぞ。
もう一回書くからな。幼稚な低脳どもが。
以下、妄想と推測による「僕の考えたSMRの仕組み」関連書き込み禁止
妄想ぐらい好きに書いても良いとは思うが、
その妄想を元に他人に突っ込みいれてきて俺様正解の青年の主張してくるのが邪魔くさい。
>>924
物理ヘッドの数は関係無いね
今のAFTだって物理セクターは4kだけど論理セクターは512だから物理/論理アドレス変換はしてる
SMR(特にWDが採用していると考えられる物理セクター毎の再配置方式)は、SSDと同じように未使用の瓦バンドに連続書き込みするためにアドレス変換をしてると考えてまず間違いない
茂のtrim実装されてない3.5インチモデルは、もう少しシンプルな方式っぽいが情報がないのでなんとも >>933
「をしてると考えてまず間違いない」
書いたそばから全く無視してこれ続けるんだな?
そういう覚悟で荒らし続けるんだな? 馬鹿には何を言っても理解できないし、自分が馬鹿だというのにもほとんど気がつかない
>>933
海門なら >>439 に公式情報があるよ
なんで海門が物理=論理で出来てるのにWDがセクタ毎の再配置なんてリスキーな事をしてると思えるのか
>>926 のバンド毎のアドレス変換で十分海門の上を行けるでしょ >>933
円盤は出し入れのパスが１つしかないことが大問題なんだよ
半導体記憶装置は好きなようにパスを作ることができるから
各ブロックを同時並行動作することができる
まそこまでアドレス変換していると主張するのならそうなんだろう
総量１T(40)/瓦1単位256MB(28)のストレージ、ホスト４Kクラスタ（12)を想定
くそまじめに４Kクラスタの変換テーブルを持つとすると２５６Mワード（２８）
nandメモリ１GBでなんとかなりそうではあるな
多少変換粒度を下げればさらにコスト減と容量アップに対応できそうだ 排除する権利があるわけでもなし。
絡んでこない限りはスルーするしかないでしょ。
絡んできてもスルーするしかないが。
>>936
>>926の資料には「MCに記録されたデータは，ディスク上のアドレスとしてシーケンシャルアクセスできるように再計算され，所定のバンドに瓦記録される。」とぼかした表記しかないな
セクター毎にアドレス変換していると取っても何の矛盾もない 8TBが18000円とかなのに、同じシリーズの10TBが45000円、14TBが70000円とかおかしくないか
こんなんどれを買うか選びたくても事実上強制やん
>>940
お前のその発言に意味があるとでも？
黙ってろよ >>939
なるほど、俺とはアドレス変換に対する考えが逆なんだな
俺はHDDがosから指定した書き込み先アドレスに変換をかける程
シーケンシャルリードが遅くなるから
アドレス変換するなら最小に留めなければならないと考える
だから変換をまったくしないとされる海門も支持するし
変換するにしてもバンド毎で十分に実現出来るものを
セクタ毎にする理由が理解できない >>944
いや、茂だってメディアキャッシュに仮書きする為には物理/論理アドレス変換が必要なんだけど...
全くやってないなんて無茶な
茂は瓦バンドに含まれるデータが変更されたとき、そのアドレスから先の内容を書き換えるって貼ってくれた資料に書いてあるね
WDは>>863 の通り極力セクターの連続性を維持する様に瓦バンドに書き込んでるんでしょ
ここの孟宗書き込みより>>863 の方が信憑性あるしな >>945
MC上のデータは揮発性だしLBA指定直接で読み書きできるわけじゃないからなあ ナンセンス
変換テーブル間接参照ということなら CMRでもやっているよね 代替セクタ
SMRなHDDでもSMART的にセクタ単位みたいね シリンダでもバンドでもないんだね
つまり代替セクタ用のリザーブエリアはCMR風味のセクタ単発RWが可能なのかもね >>863
> データ復旧業者が直面するSSDのデータ救出困難。スマホはまず不可能、悪徳業者に注意を
> https://pc.watch.impress.co.jp/docs/news/1192004.html
> ＞HDDに関しては、SMR(Shingled Magnetic Recording)技術が使われているものがあり、
> ＞ガベージコレクション後にブートレコードが移動してしまうことや、従来のCMRのように
> ＞最終セクタの位置が容易に特定できるように書き込まれず、LBA変換テーブルで記録
> ＞場所が制御されることなどから、こちらも復旧の難易度が高くなっている。
アホ草 まなんでもいいや
アドレス変換をするのならなおさら
ホストが余ほど暇な運用環境でないと
成り立たないくそ方式であることは明らか
逆に言えばホストが死ぬほど暇であれば何の問題もない方式であるともいえる
nandメモリのような制限がないHDDにおいては
ローカルにアドレス管理する意味は全く無いね
瓦に起因する最適化はシステム側のドライバ層に組み込むのがベストであるし
将来的にはそうなると予言しておく
失敬
将来的にはHDDは半導体ストレージに駆逐されるのだったｗ
トンネル効果怖い
長期保存はやっぱり磁気媒体のほうがまだ安心
なんか、すごいよな。自分の理論構築によればSMRが遅いとかありえないって感じで。
むしろ、OSと使用者の問題に尽きるのでSMRを推進していきたい！とかで。
>>945
茂の場合は
osに公開している論理アドレス=瓦領域の物理アドレス
で瓦書きが必要な書き込みデータは一旦論理アドレスと共にMCに書いて
後で瓦領域の本来の書き込み先に非同期に瓦書きするって事でしょ
アドレスから先の内容を書き換えるってのはこの瓦書きの話
書き換えるではなく再書き込みだけど
で、最終的に書き込まれる先はosの指定した通りのアドレスになるから
アドレス変換されるとは言い難いかなと >>949
MCことメディアキャッシュは不揮発領域に確保されてるキャッシュ
一台のSMR内の最外周に20GB程確保されてると言われてて
使用目的は時間のかかる瓦領域への瓦書きを後回しにすること
なのでそもそもSMRはホストが暇じゃないと成り立たず
暇が無いと >>238 のようにMCがいっぱいとなり
ホストからの書き込みがMCから瓦領域への瓦書きによりMCが空くまでまたされる事になって
とんでもない遅さになる 実際の書き戻しに要する時間とかそのタイミングとかって判明してないんでしょ？
以前に出てくるSMRの不具合報告と、最近の報告を考えると
以前は書き戻しはアイドルタイムにするようにしてたけど、
最近は定期的に割り込ませてるんじゃないかという気はする。
ファームでチューニングできる分野だし、
ひとまとめに書き戻し=激遅状態ってのはどうだろうね
>>938
絡まれた場合でも、スルーすると
相手の反論を受け入れたと取られてもしかたがないのがやっかいだけどね。
本人はともかく外野にもそう判断されかねない。
まあ、真面目に付き合っても埒が明かないレベルはどうしようもないけど、
こういうのがいるとスレの情報価値が一気に下がるんだろうなあ。 >>956
以前ってのがいつだかわからんけど >>9 を見る限りホストの書き込み処理中でも
MCからの瓦書きはやってるのだろうね
というか完全なアイドル中なんてのが来る保証も無いから
何れにせよある程度ホストの処理に被ってもにやらざる負えないだろうと思う
とはいえ激遅にならないためにMCがあるんだからMCに空きがあるのに激遅になるような
チューニングにする程メーカーはアホでは無いと思うけど 価値もなにもここは隔離スレだよw
延々と長文書いても結論なんか何一つ出ないんだから
他所でやると嵐認定されるわ
ﾜｯﾁｮｲ fe11-Eaty さんは中々考察できる人みたいだけど、いかんせん知識不足。
このスレだけでも読んでみると色々面白いと思うよ。
>>917
連続 LBA アクセスを検出して直接瓦書きすることもあるよ。
>>949
前段。根本的に SMR とはそういうもの。多かれ少なかれ暇な時間を必要とする。
最悪時に破綻するのはさけられない運命の中、
なるべくユーザに遅くなったと感じさせないよう工夫したり、
破綻するのは仕方ないものとしてそれまでのパフォーマンスを優先する等、
様々な方針が考えられる。
後段。ホスト側で制御する方式はすでにある。
製品としても少なくともサンプル出荷はされているが実働しているかは不明。
一般レベルでは MS に動きがない限り普及することはないでしょう。 >>912
ちょい高度な話になるので、できれば SMR を理解してから読み直して。
アドレス変換なしもしくはバンド（瓦最小単位のこと）単位変換方式では
メディアキャッシュのバンド単位管理はありえると思う。
有効セクタが少なくすかすかになりがちなのが難だが逆に言えば吐き出しが容易。
かき集める手間もなく状況によって作業時間が大きく変わることもない。
ただ、瓦の書き換えは本当に大変な作業なので
（一説にはバンドひとつあたり数秒、理論上最短でも一秒弱はかかる計算）、
管理情報のように頻繁に書き換えられるものは
なるべくメディアキャッシュにキープし続ける戦略も考えられ、
この場合セクタ単位でぎっしり管理したほうが沢山キープできるので
どちらがいいかは微妙なところ。 >>956
その人は何度説明しても >>342 から一歩も前進しないので言うだけ無駄。
RAID コントローラから切り離されてしまうリスクとかまったく理解できないみたい。 >>959
もちろん隔離スレだと思ってるｗ
他者の考えを知り各々の中にある正解が変化する。
それだけで十分意味があるんだよ。
大多数が納得すればスレとしての結論にはなるかもしれない。 で、妄想スレの住人は、本スレに一切書き込みを行わないこと。
たとえ一般的な話をしようとも、お前ら絶対に推測持ち出して争いになるから
自重しろ。お願いとか言わんぞ。もう堪忍袋の尾は切れてる。
>>965
タイミング的には丁度良いな
特に反対する理由もないし分ければ良いよね、維持できるかは知らんけど 本スレが過疎って、推測スレが賑わって世間的にも
有用な情報構築ができればそれで良いと思ってる
俺は荒らしたり攻撃したいわけじゃない
重要なのは、目的が違う相手が考えを押し付けられたり
エビデンスの取れてない推測情報でスレを溢れ返らせて
実用情報を欲してる人が迷惑している状況を改善したい
このスレにはスレタイをもとにいろんな人が来ていると思う
SMRの実用的運用情報が欲しい人に対して、SMRの技術に
関心があってとことん知識欲を満たして語り合いたい人が
ちょっと「やり過ぎてる」ことを自覚してないのが問題なんよ
電車でいえば運行情報を知りたい人に鉄オタが喧嘩売ってる状態
A「なんかこないだ乗った特急電車、乗車率120%超えたら、
A駅で乗り換えのはずが通過して、何のアナウンスもなく
各駅停車になったんだけどありえない」
B「新型車両はそうなるらしい。でも何の掲示もアナウンスも
されてなくてみんな困ってる」
異常者「A駅で乗り換えるとかw そんなの普通の乗り方じゃないし。
120%の乗車率とかも異常。120%の乗車率になるとかありえない」
A「えっ」
B「えっ」
A「どうしたら目的地に予定通りつけるか教えて」
B「現状識別無理だから、別の公共交通機関を検討しないと…」
異常者「いやいや、普通に乗れよ。おれこないだ乗った※1けど
大丈夫だったし、ありえんわ。 おかしいって言うなら、乗車率
みたいなアバウトな指標とか120%とか起こりえない指標じゃなく
現実的に正確な条件提示してよ。そんなことより新しい機種は
〇〇方式のブレーキを搭載してるから、速度が落ちすぎないよう…」
A「なんやねんこいつ」
B「なんやねんこいつ」
>>967
気になるのはその目的っていうのは具体的にはなんだろなと
例えば「テレビ録画用にSMR買って大丈夫？」って質問はどっちのスレに書くべきか？
本スレではエビデンスを揃えて答えないといけないから
本スレに書かれてエビデンスが揃えられればそのまま本スレで答えられて
そうでなければ推測スレに誘導されるって流れかね 無粋だなあ
パズルを解くように中身のつくりについて色々と想像するのは楽しいじゃん
>>964は引用しただけでもまさにこの通りのスレタイにしようというほど
厳密な提案ではないです(´･ω･`)
「推測」という縛りもどうかと思ってきたし、難しいね
スレタイの文言は別として、各スレの目的はこんな感じはどうだろう
実運用スレ：使い道、使い方、一般知識
・SMRのHDDの使い方、実際の挙動報告とか、所有者によるアドバイス
目的別実製品の推奨／非推奨のアドバイス
※使い方に関する推測を含む意見は許容する
仕様スレ：技術仕様メイン
・技術的な『仕様』を解明するスレ
仕様に関する推測妄想未来予測大歓迎で語り合おう >>970
それはいいけど、技術仕様論ずる奴らの中の一部の人が
実運用の中で困った人の作業内容を極端な使い方だとか
そんな作業するの一回だけでしょとかレッテルを貼って
否定したりするのを繰り返してきたのが問題なんだよね
だからスレを分ける意見を出した
みんなが要らないというならそれで良いけど、分けないなら
SMR盲目的推進派も絶対否定派も、理論大好きっ子も
みんな仲良くやっていって欲しい(´･ω･`) １Tストレージを４Kクラスタでアドレッシングしても高々１GB程度
いくらでも追尾は可能なんだからどうにでもなる
どうにでもなるがどうやっても一長一短でてくるんだからどうにもならん
ホストの空き時間を使ってローカル自律で並べ替えも考え方の一つだが
SSDのような制約もないいくらでも上書き可能なのに
ローカルアドレスを制御するデメリットはでかすぎると思う
OSのドライバ層に並べ替えを組み込むのがスマート
デフラグツール（SMR専用の）で並べ替えても
自律で並べ替えても
総時間は同じ
操作者がその時間を認識するか
認識しないかの違いだけなのである
>>968
どういう例えなのかよくわからんｗ
>>971
大分曖昧になってきたねｗ
推測を許さないと断片化に気をつけようというようなアドバイスもできなくなっちゃうからなあ。
何が事実でどこからが推測なのかを明確に線引きするのは難しいんだよ。
あなたの希望を叶えるのは初心者スレなんじゃないかという気もする。
上から目線で申し訳ないが技術話についてこれない人向けの。
>>972
それが問題だとわかっているなら、
そういうレスをする人にピンポイントで注意すればいいんじゃないかな。
可能性として話してることを、理解もできずに全否定する人なんかも
ついでに叩いてくれると個人的に助かるｗ >>973-974
だから、そういうのが実現すれば理想的なのはみなわかってるんだけど、
現実はそう動いてないのよ。
それどころかメーカーは SMR であることを隠蔽してる有様。
なので、なるべく CMR（SMR との対比で生まれた言葉で普通の HDD のこと）同様に
使えるようにするにはどうするべきかね（どうやってんのかね）って話がメインになってる。 >>962
RAIDコントローラから切り離されるリスクというか
>>11 よりSMRは一部RAIDでは使えないってのは現状では事実みたいだよ >>961
実際には HDD 内の管理領域はそんなに更新されないって >>591 で言ってるみたいだけど
MC にキープってのも何を判定してキープするのか謎 次スレも立ってることだし、たまには相手してやるか。
>>978
Drobo のは動作保証はできないという意味で、機器側としては真っ当な主張だな。
タイムアウトを長めに設定できるようにする道もあるが、そんなのはポリシー次第だ。
HDD メーカーが SMR ということを隠して売っているのだから、
本来は CMR 同様に使えなければならないという話なのがわからないのか？
何が「事実みたいだよ」だ。物事の本質が見えてないんだよ。
>>979
>>591 の最後の段落は理解したのか？
CMR ですら無視できないロスになるのである程度はまとめてるって話だろうが。
少し減ったところで SMR にとって大変であることに変わりはない。
字面だけ見て薄っぺらな判断しやがって。
何が「そんなに更新されないって～言ってるみたい」だ。書き手への侮辱だぞ。
二行目については聞き飽きたわ。いい加減にしろ。
まったく、相手やめたのをいいことにちょこちょこ過去レスにまでイチャモン付けやがって。
なんとかこちらの間違いを指摘してやろうとか考えてるなら、
そんなことやってるからいつまでたっても正解に近づけないんじゃないのか？
まあ、悪意もなく純粋に知的好奇心だけで動いてるようにも見えるしよくわからんが、
いずれにせよ大迷惑になってることにいい加減気付いてくれ。 このスレを最近訪れた方へ。
やたら上から目線に見えるとは思いますが、これまでの経緯あってのことですので、
スレに目を通したあとでの判断をお願いします。
もちろん興味ないなら気にせずスルーで。
>>980
少し減ったところでって >>591 はwin7だと6万ファイル書いた時の
HDDへのコマンド発行数が5万だったって話でしょ？
管理情報を書くのが大変って感じがしないけど？ >>980
聞き飽きたというかキープ判定はSMRがアクセス解析してやるって言う抽象的な話だけで
それ以上の具体的な事は語られて無いと思うんだよね
SMRがアクセス解析するってので色々疑問は尽きないけど、例えば
NTFSで暫く使った後にFAT64にクイックフォーマットしたら
FAT64使ってるけどSMRはNTFSの解析結果で動くんだよなーとか >>982
まだわからんのか？
５万回ってことはバンドひとつの書き換えが１秒だったとして最悪５万秒かかるってことだぞ？
で、現実には有り得ないが、もしもすべての書き込みが何であるのか把握できるなら、
ディレクトリ以外の管理情報はそれぞれ数回からせいぜい数十回、
ディレクトリについてはファイルと一緒に書き込めるので実質０回となる。
が、未来予知が不可能なのはもちろん、どれが管理情報なのかすらわからないんだから、
アクセス解析により予測し理想に近づけるしかない。
こんなような話は何回もしてるが、お前の反応はいつもこうだ。
「（勝手に理想に近い動作をする仮定で？）大変じゃないんじゃない？」
そのためにはアクセス解析が必要と説明しても
「（なぜか理想に近い動作をできる仮定で？）そんなの必要ないんじゃない？」
どうすれば伝わるのかもうわからんよ。
相手が間違ってる前提でなんとか辻褄が合うように考えてしまう腐ったロジックでもあるのか？ >>983
フォーマット変更なんてせずともディレクトリを削除しただけでそういうことは起こり得る。
Trim があれば大丈夫だが（アドレス変換なしでも有用な例）、デフラグで移動したとかね。
しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。
具体的に何をするかは、繰り返しアクセスされたり最近アクセスされたものは
またアクセスされる可能性が高いだろう予想するというような一般的なことには言及したぞ。
それ以上は色々考えられるのではっきりしたことはわからないが、
自分が作るならこんな感じかなと妄想したことはあるので例として言ってみようか。
・ライトアクセスで +10 リードアクセスで +1 のポイントを与える
・時間経過もしくは総アクセス回数に応じてポイントを少しずつ減少させる
・キャッシュエントリが不足した場合、ポイントが小さいものから処理する
古過ぎる情報をあまり覚えていても前出の件のような場合に邪魔になるので
ポイントには上限を設けたほうがいいと思う。
「処理する」は「捨てられないものを瓦書きして捨てられるものにする」
と「捨てられるものを捨てる」のいずれか（場合によっては同時）で、
基本的には後者が先に行われるが、
ポイントが非常に高い場合には残しておいたほうがいいかもしれない。
また、アドレス変換なしでキャッシュ管理がセクタ単位の場合、
>>742 でも触れたようにバンドごと残しておけば書き換え時にメリットがあるものの
なるべく沢山キープするという戦略も考えられるので
ポイント管理をセクタ単位にするかバンド単位にするかは微妙。
あくまで妄想だからなｗ >>984
すまん書き方が悪かった
>>591 はwin7で6万ファイル書いたらHDDには全部で5万コマンド発行されて
そのうち管理情報アクセスが1.3万回という話だそうだ
なので1ファイル1回未満の書き込みにそんなに必死になる必要ある？という疑問になる
というかレス書いた当人かと思ってたが違うのか >>985
古いデータを捨てるならポイントと一緒にタイムスタンプも取っておかなくてはならず
それを全バンド分持ち続けることになり
そんなもの持ってるからフォーマットしても論理的に初期化されないぶっ飛んだHDDになると
このスレも終わりだから言っとくとアクセス解析とか言い出す前は頭良さそうだったのに
なんでアクセス解析云々言いだしてこんなんなってしまったのか不思議でしょうがない
別人なのかな？
アクセス解析なんて理解してない俺だけしか触れてないって所は察しても良い気はするが >>986
いや、本人だよ。
ファイルシステム的に必要なはずの回数よりは少ないが極端に少ないわけでもない
ということが大事で具体的な回数は重要ではないので覚えてないし確認もしなかっただけ。
１万回だとしても大変なことには変わらんだろう。１万秒が何分なのか計算してみ。
あと、ちょっと間違えてた。お前とはまっさら状態での考察ばかりしてたので（言い訳）。
一般的にはディレクトリが割り当てられるクラスタがファイルと隣接するとは限らないので、
二段落目は正しくはこうかな。
～管理情報はそれぞれ数回からせいぜい数十回、
ディレクトリについてはファイルと一緒に書き込めて実質０回となる場合もある。 >>989
いや、タイムスタンプはいらない。
アクセス頻度とアクセス時刻に重みを持たせつつひとつにまとめるためのポイントなんだよ。
「少しずつ減少させる」で何が起きるのか考えてみ。
「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
そもそも、予測が当たれば効率が上がるというだけで、
外したところで大きな問題になるわけでもない。
最後の一文はこちらに察しろって言ってるのか？ なら逆だ。
おかしいことを言ってればほかからも突っ込みが入るはずだ。
ましてやお前を叩いてるんだし怒る人だっているだろう。
そうならないのは、どこまでやるべきかはともかく、
アクセス解析という考え自体に異論のある人はいないということなんだよ。
常識レベルの知識だし、キャッシュという概念から自ら思い付く人だっているだろう。
理解はできないが「ふーん、そういうもんなんだ」みたいな人もいるかもしれない。
お前の問題は、理解できず明確な理由をもっておかしいと指摘できるわけでもないのに、
「そんなことする必要はなさそう」という曖昧な理由で否定するところだ。
理解できないなら必要ないかどうか判断なんてできないんだよ。
掛け算できない人が「繰り返し足しゃいいんだから掛け算なんていらなくね？」
って言ってるようなもんだぞ？ >>991
それを言ったらお前は管理情報書き換えがなんとなくヤバそうっていう曖昧な理由で
フォーマットしても初期化されないユーザーもメーカーも望まない
致命的な欠陥HDDが作り上げられてるって吹いて回ってるんだよ
1万回でも大変っていずれにせよファイル本体で4万回書かなくてはならないのにどこが大変なんだっつーね
しかもアドレスが同じなら瓦書き時にMC上でマージされて消えるし >>992
5万秒のうち1万秒は20％。4万秒が既に大変ってのはyesですが20％は結構な量→200Mで書けるHDDの期待値が160Mになる
解析してるかどうかは判らないし俺様理論である事には変わりませんが「大した事無い！やってる訳無い！」ってのは乱暴と思うよ。
まぁコスト(bugコスト含む)の面でヤってないと私個人は思いますがw >>993
ああ、やっとそんな事やってるわけがないって事がわかって貰えたか
いやある程度の知識と読解力が無い人に理解してもらうのは大変だな >>994
ん？
念のためですが、私は別人で かつ個人的意見はやれば効果あるだろうがコスト面でヤってないんじゃね？ですよ？ >>992
なんとなくヤバそうなんてレベルじゃないんだよ。
１万秒は計算したのか？ ３時間近いんだぞ？
じゃあ、ファイル本体は４万回で４万秒で１１時間かかるのか？ おかしいだろ？
お前は答を直接書いても頭に入らないようなので自分で考えてみろ。
落ち着いて考えればどこで間違えたかわかるはずだ。
やっぱり（少なくとも今の）お前は相手の間違いを見つけてやろうということに必死で、
肝心なことに頭がまわってないように思えるな。
フォーマット時に不適切な挙動が発生する可能性に気付きそればっか考えてるんだろう。
＞しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。
＞「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
＞そもそも、予測が当たれば効率が上がるというだけで、
＞外したところで大きな問題になるわけでもない。
と説明したのに、「理解できず明確な理由をもっておかしいと指摘できるわけでもないのに」
「致命的な欠陥HDDが作り上げられてる」とか妄想して攻撃できてるつもりになってるわけだ。 >>993
あなたも考えてみてね。
「ファイル総サイズ392,336,035バイト」書き込むのに１４時間かかってどうするの？
バグの心配をするなら、一番古いものから処理するだけでいいんじゃないかな。
単純だがこれもアクセス解析の一種。結果的にアクセスパターンを追ってることになるからね。
これだけでも単なるコピー程度なら無駄書き換えは大分減らせると思うし、
彼が気にしてる問題もすぐに解消するので欠陥とか言わせないｗ >>992
あ、念のためだが、お前がその記事を持ち出してきたのでそれに付き合っただけで、
メディアキャッシュに丸々入り切るサイズなのだからとくに工夫する必要もない。
全部溜めてから吐き出せば理想的な書き込みができるとか馬鹿なことを考えるなよ？
最終的には、溢れる可能性がある規模のケースに置き換えて考えないと意味ないからな。
念のためだが「この記事を持ち出したのはそっちだ」とかいうおかしな反応が予想されるので、
管理情報をある程度まとめ書きしていることの根拠として出しただけだと先手を打っておく。
流石にないかｗ >>993
ああ、別人だったのか
こんなの触るの俺だけかと思ってたからてっきり当人が改心したのかとw
そう言いながら自分はやるわけないと思ってるなら同じ事じゃないか？w >>996
まあ普通に考えたら5万秒、4万秒共にアウトか共にセーフかどちらかで
前者ならアクセス解析ではなく別の対策をするべきじゃないかと
アクセス解析では5万秒を4万秒にする事しか出来ないでしょ？
5万秒はアウトで4万秒はセーフだからアクセス解析でなんとかすべき
なんて方がアクセス解析したい人の都合の良いサンプルの抜き出しじゃないかとね
10万秒と8万秒でも同じ事
結局20%しか向上は認められないわけだし
MCのサイズを調整した方がお手軽で現実的ではないかと mmp2
lud20190719010117ca
このスレへの固定リンク： http://5chb.net/r/jisaku/1554303763/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「【瓦記録】SMRのHDD 6台目【ﾌﾟﾗｯﾀ枚数減】 ->画像>23枚 」を見た人も見ています：
・.
・ん
・
・ん
・わ
・閖上
・i
・わ
・竈
・
・肛
・澤
・
・も
・0
・ん
・
・
・南
・皮
・:
・o
・m
・報告
・.
・報告
・f
・五帝
・1
・闇
・6
・c
・て
・最低
・/
・|
・s
・.
・^
・k
・D専
・ﾅﾊ
・1
・d
・な
・報告
・b
・豚
・便器
・.
・ω
・z
・_
・.
・[
・て
・阪神
・t
・雑
・h
・t
・9
・に
・暇
・借金
・D
16:23:27 up 5 days, 2:47, 0 users, load average: 7.62, 9.24, 9.95
in 0.039629936218262 sec
@0.039629936218262@0b7 on 121706
|
