【瓦記録】SMRのHDD 4台目【ﾌﾟﾗｯﾀ枚数減】
レス数が1000を超えています。これ以上書き込みはできません。
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
プラッタ枚数を減らし、価格が安くなるかわりにがランダム書き込みが致命的に遅くなる技術
Shingled Magnetic Recording (SMR)を採用した、通称瓦記録のHDDについて語りましょう
Shingled Magnetic Recording: Boosting Capacity and Lowering Costs
https://sata-io.org/developers/sata-ecosystem/shingled-magnetic-recording-boosting-capacity-and-lowering-costs
HDDの大容量化をけん引する瓦記録技術 - 東芝
https://www.toshiba.co.jp/tech/review/2015/08/70_08pdf/a08.pdf
SMR におけるビット信頼度への隣接ビットの影響 - 日本磁気学会
https://www.magnetics.jp/kouenkai/2015/doc/program/44ALL.pdf
スマートストレージ・スタックベースHBAおよびRAIDソリューションでのSMRドライブの使用
https://storage.microsemi.com/nr/pdfs/microsemi_adaptec_smr_whitepaper_ja.pdf
前スレ
【瓦記録】SMRのHDD 3台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1541073336/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured 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) 〃´⌒ヽ
., -―― ﾒ／_´⌒ヽ
／ ／￣ ´ヽ ヽ
./ , /// ﾄ. ! ､ 丶ヽ
l / /（(（リ从 ﾘﾉ）） '
| i l ． ヽﾉ ．V l
l ,=! l /// ///l l ねんがんの１４ＴＢをてにいれたぞ！
l ヾ! ', l ヽ_フ l l
| ヽヽヽ //
l ヾ≧ , ＿_ , イ〃
li （´｀)l {ﾆ0ﾆ}､ |＿"＿＿＿
li /l, l└ ﾀl」／| ＨＤＤ |
ﾘヽ/ l l__ .／ |＿＿＿＿＿|
,/ L__[]っ ／ ( ⌒ ) ／
::::::::/ ヽ、 :: ::: ::: :::::::::::::::::::::::::::::::::
:::::/ lﾊ ::: : :: :::::::::: :::::::::::::::::::::::::::::
::::l l /ﾉﾘ ::: : :: ::::::::::: ::::::::::::::::::::::::
:::| /） / ::: : :: ::::::::: :::::::::::::::::::::::::::::
::l /ｲ/| . :. :. .:: : :: :: :::::::: : ::::::::::::::::
/ / ||/ /￣￣￣￣￣７l:::::::::::::::::::
i /_,／i!/ ⌒⌒⌒⌒⌒/ ,l::::::::::::::::
l 人 /⌒⌒⌒⌒⌒/ /::::::::::::::::
l / /⌒ヽ⌒⌒⌒⌒⌒/ /::::::::::::::::
l /iｌ | ） ⌒⌒⌒⌒/ ./::::::::::::::::
ll l i! ｀ｰ、＼＿＿＿_ / ｎ/::::::::::::::::
lヽ l |＼. ＼ /⌒〉:::::::::::::::: 外付けHDD欲しいんだけどSMRだったら嫌だな
指名買いできる所ないかな このスレのテンプレにSMRHDDの型番一覧表って無いの？
3.5,2.5インチ別であれば便利なのに
それとも最近のHDDは全部SMRなの？ 2Socket774 (ﾜｯﾁｮｲ 5bec-zkh5)2018/03/28(水) 12:22:39.69ID:sOi+OkVg0>>17
SeagateのSMR HDD
SMR(瓦)
ST2000DM005
ST3000DM007
ST4000DM004
ST6000DM003
ST8000DM004
Archive HDD(瓦)
ST8000AS0002
CMR
ST500DM009
ST1000DM010
ST2000DM006
ST3000DM008 >>7
百度に古いHDDリストでSMR区分記述があるページがあったが古過。URL失念。
SMR云々は別として、1010種類のHDDのベンチマークリストはあるね。結構新しいし便利。
UserBenchmark HDD
https://hdd.userbenchmark.com ST4000DM004買って内蔵にし別の外付けUSB-HDDから
画像・動画等約500GB・5万ファイルコピー(ROBOCOPY)したら1時間弱だった
システムドライブやRAIDに使わなきゃ特に問題ないんでしょ 多分 え？20GB超ファイルコピーしたら0.02MB／Sになるって聞いたんだが違うの？ ファームがランダムライトと判断するデータが
メディアキャッシュ容量以上に連続して(書き戻し時間を与えずに)送り込まれると
やりくりできなくなって遅くなる 倉庫用にSeagateの8TB買って最初に大量コピーしたらクッソ遅かったなあ
その作業さえ終わってしまえば後は普通のHDDと大差ないけど ミラーじゃないRAIDなら、束ねたぶんキャッシュ増量なのでもう少し早くなる SMRは分散パリティなRAID5や6で使ってはいけないよ
パリティブロックへの書き込みがあるから基本的に全部ランダム書き込みになるから、
早くなるどころか逆に遅くなるだろうよ
前スレでSeagate BarracudaシリーズのデータシートにRAID0か1にしか適合してないっていうの出てたと思う ソフトウェアRAIDで4TBx6と6TBx6使ってる
前者はじきに一年経ちます が、どうもないですよ
詳しくは過去ログ見てください
> パリティブロックへの書き込みがあるから基本的に全部ランダム書き込みになるから、
この理屈は明らかにおかしい >>22
まあ、その危険性は想定すべきだろうね。制御板ベースのRAIDなら当然ドライバーが
HDDとOSの間に介在する。シーク動作指定直後の書き込みはおそらくメディアキャッシュ上に
書き込まれるだろうからせっかくOSが連続書き用にブロッキングしていても、糞ドライバーが
小刻みにシーク命令挿入すればメディアキャッシュは簡単に言うと満杯になりやすいだろうね。
HDD上のRAMが256MBだから64～256MB max単位でキャッシュ埋めが発生するのかもしれない。
>>23
ソフトウェアRAIDはなんちゃっての類だから、MSのデバドラを置き換えてHDDに書き込んだりは
しないんじゃないの？ シーク挿入しなければ、通常カキコと動作的に何ら違いは生じないと思うけど。
それと、25-30gb以内の連続ランダムカキコならそもそも問題はほぼ発生しいないだろうし。 >>24
ちょっと何言ってるかわかりませんね、とりあえずお薬出しておきます >>26
お薬必要なのは君かと
通常のRAIDコントローラーは、データ書き込みと同時に違うハードディスクにパリティ情報を書き込む
ブロック単位でパリティを作るから、ランダムアクセスになる
ファイル単位じゃないからね SMRは読み込みだけは速いからゲーム専用ドライブに最適やぞ
ダウンロード販売のゲームを落とす時の書き込みは必要なファイルが順番に書き込まれるシーケンシャルやし
ネットゲームの更新も更新分のデータが順番に書き込まれていくシーケンシャル書き込みなので遅くならない
最近のゲームは1タイトル60GB～100GB当たり前だから1TBのSSDに入れてるとすぐ満杯になるがHDDだと余裕 そういう用途はSSHDの方が向いてそうだけど実際どうなんやろ >>28
ゲーム機専用のSMRといえば、firecudaでしょうね。７ｍｍ 2.5インチのハイブリッドSSHD
1TBが7500円、2TBが11000円弱程度。直近プレイ中ゲームを小容量とはいえSSD上に
キャッシュするのでロード時間短縮できるとか。積みゲーはSMR瓦にうっちゃっておける。 読み込み速いといっても、プラッタ世代なりの速度でしかないから
わざわざその為に選ぶほどでもないだろう。
価格のわりにはって程度だな。 ダウンロードにしろアップデート更新にしろ、シーケンシャルになるのは
それらを書き込んでる間に他の書き込み処理がいっさい割り込まない場合に限っての話だな。
バックグラウンドでダウンロードが走る場合も多いし、
ダウンロードがシーケンシャルは期待できなくね？
ドライブのライト速度と比べてダウンロード速度は普通は遅いし。 スペック上だと2TBプラッタのSMRドライブのリード性能は1.33TBプラッタ以上、1.5TBプラッタ未満だな。
SMR領域はセクタ間のギャップが無い？らしいから、1.33TBプラッタの磁気記録密度でもデータ記録の効率がいいと思われる。
プラッタ世代としては1.33TBプラッタなのかね。 >>27
ブロック単位でパリティ計算するからランダムアクセスって意味がわからないし
そもそもRAID5のパリティはストライプ単位なんだが >>27
チャンク単位で書き込んで、各チャンク（=ストライプ）は連続したブロックだよ
妄想垂れ流しは論外 鉄狼にもメディアキャッシュあるんだね。MC付きのCMR？ のMCがオーバーフローしたらどうなるんだろう？
一般的なHDDとNAS用HDD『IronWolf』との違いが明らかに！主席技師に聞いたそのスゴさとは
https://weekly.ascii.jp/elem/000/000/415/415975/ チャンクサイズとSMRのバンドブロックがどれくらいのサイズ感覚なのかよくわからないんだが、
SMRのファームにとってシーケンシャルと言えるくらいのサイズなの？
適当にぐぐった程度だけど256KBとかそういう数字が出てくるんだけど。 >>36
ストライプサイズ＝ブロックだよ
RAID5の書き込み時の動きは、ファイルをストライプサイズでぶつ切りにして分散して書き込んでて、
データチャンクへストライプサイズの書き込み終わったらパリティ計算してパリティチャンクに書き込みね
そしてデータチャンクとパリティチャンクは分かれるんだけど、ヘッドがどういう動きするのか説明必要なのかね
パリティチャンクがSMR領域にあった場合にパフォーマンス悪化するのも容易に想像できると思うんがね >>39
SMRの瓦バンドのサイズは20～40MB程度みたいね。外周と内周とではトラックあたりの
セクター数が違うみたいだから固定サイズではないみたい。メディアキャッシュは最外周。
NTFSのMFT(ディレクトリエリア)はMC隣接の外周部でHDD全体容量の約2.5%を固定占有。
Skylight A Window on Shingled Disk Operation
https://www.usenix.org/sites/default/files/conference/protected-files/fast15_slides_aghayev.pdf >>40
＞そしてデータチャンクとパリティチャンクは分かれるんだけど、ヘッドがどういう動きするのか説明必要なのかね
は？
データはデータ、パリティはパリティで別のディスクに書き込まれるんだけど？
ヘッドがディスク間を移動するわけ？ >>44
君が1つのファイルが書き込み終わるまでにパリティがずっと同じディスクに書き込み続けられると
思ってることは理解したよ
RAID3,4のパリティ専用ドライブとRAID5,6の分散パリティを違いを勉強しようね >>45
だからパリティはストライプ単位って言ってんだろ、専用ドライブなんていう話してないんだが
専用ドライブだからパリティ書いてもシーケンシャル、分散書き込みされるからランダムアクセスなんて結局意味わからないし
この図みてパリティ書き込むドライブが専用だったらアクセスの仕方が変わると思うわけ？
パリティだけストライプと関係ないディスクの端っこにでも書き込むと思ってんの？
https://itsakura.com/wp-content/uploads/2017/12/server-raid3.png ファイルシステムより下のレイヤーにファイルなんていう単位はないし >>45
パリティはデータを書き込んだのと「違うドライブで同じセクタアドレス」に書き込まれるよ >>40
そしてセクタは細かすぎるので複数のセクタをまとめたものがチャンク、チャンクをRAIDの台数分まとめたものがストライプね 頼むから日本語でお願いします
理解できないのを意味が分からないって言ってる人に説明するのは難しいけどさ
>>46-49
ストライプサイズっていうのは、ファイルシステムのブロックサイズ（クラスターサイズ）みたいなもの
謎解釈してるけど、チャンクサイズっていうのはストライプサイズと同義
論理ドライブと物理ドライブのアドレスの区別が付いてなさそうだけど、
ディスク3本でRAID5のパリティ書き込みパターンはこうだよ
https://www.ibm.com/support/knowledgecenter/ja/POWER8/p8ebk/raidfive.htm
図の下のほうの︙は繰り返しっていう意味ね
パリティ間に挟まるから連続しないし、ずっと同じディスクに書き込むんじゃないんだよって
何度書いたらいいんだろうか SMR処理をする上でメリットとなるシーケンシャル扱いされる為には
RAID456のチャンクサイズでは小さい
そのためSMR処理でシーケンシャル扱いされる為には
チャンクの書き込みがSMRバンドブロックサイズを上回るほど連続して送られてくる必要がある。
ってことでいいのかな？ 追記みたいな連続したセクターへの書き込み指令は
RAIDでのチャンクの連続した書き込みでもシーケンシャル扱いされるかもだけど、
例えばシングルドライブで20MBのSMRバンドにシーケンシャルで書いてもらうには20MB以上の連続データが必要と思われるが、
RAIDの場合は分散されることを考えると例えば4台RAIDの場合は60MBの連続したデータでないと
シーケンシャル扱い処理にならないってことになる？ RAIDも0/1ならほぼ単ドライブアクセスみたいなものだけど
他はドライブの数で分割書き込みされるからシーケンシャル扱いにはなりにくいのかもね。
書き込みデータの大半がメディアキャッシュ送り／経由になるとして、そのメディアキャッシュも
ドライブの数分あるから、タフなハードウェアみたいな感じ？
100GB程度なら普通かもだが8TB分のファイルコピーとかだとどうなっちゃうのだろう。 >>50
＞パリティ間に挟まるから連続しないし
たがらこれがいみわかんねーって言ってんの
一つのディスクにデータ→パリティ→データだとランダムアクセスになってパリティ→パリティ→パリティだとシーケンシャルになるっていう根拠はどこから出てきてんの？
なんでお前の中ではパリティだけデータと物理的に離れた位置に書き込むことになってるわけ？
＞ずっと同じディスクに書き込むんじゃないんだよって
ずっと同じディスクじゃないから何？
RAIDコントローラがパリティだと余計なシークが発生するようにわざわざ離れた位置に書き込むと思ってる根拠は何なわけ？
https://www.ibm.com/support/knowledgecenter/ja/POWER8/p8ebk/arebj506.gif
なんでこれが自説の補強材料になると思ってるの？ちょっと頭悪すぎない？
あとストライプって用語はお前が最初に貼ったサイトと同じ意味で使ってるから RAIDのストライプとSMRの瓦ブロックは全く対応していなくて
RAIDのストライプが瓦ブロックを跨いで居るのだと思うけど
その影響ってどうなん？ ファームウェアが非常に巧妙かつ狡猾だからな
今あるベンチマークではその欠点を暴くことは絶対に出来ない
絶対にだ >>50
同義だとして論旨は変わらないよ
パリティが間に入ったからと言って、ドライブのファームウェアがこれから書き込む論理アドレスを変えるだろうか
単品ドライブが
D0 D1 D2 D3 D4 D5 D6 D7
と連続するところ、
4台RAID5のいちドライブだと
D0 D4 D7 P10-12 D13 D17 D20 P23-25
と書き込むなら
ファームウェアから見てDとPに違いはあるかって話 自分の用途においてSMR HDDが使えるかどうかテストしてみた。
用途
デジタルカメラで撮影した静止画データの保存(20MB程度のファイルが約6270個 計121GB)
保存用HDD
IOデータ製外付けHDD(ドライブ：ST4000DM004)
結果
CMR HDDで行ってるものと同じ方法でコピーをしたが、転送速度が半分程度しか出ない。
CMR HDDでは15分前後で終わる作業が32分かかった。
結論
自分の用途にはSMR HDDは使えない。
SMRでもコピーに要する時間がさほど変わらなければ、将来的にはSMRを使うことも考えてたけど、
この結果を見ると無理。今はWD青を使ってるけど、WDがこのクラスのHDDをSMR化してしまった場
合は、だいぶ割高になるけどNAS用に切り替えていくしかないのかな？ >>60
初回は全データを移行するわけだからそこは我慢
次からは継ぎ足しな訳で、大して差は出ないと思うけど
そう言う使い方が倉庫でしょう >>60
ついでにファイルシステムとアロケーションユニットサイズorクラスタサイズも教えて SMRとCMRの型番と接続方法、コピーに使用したソフトは？ CMR HDD
WD青6TB(HDDケースで外付け)
NTFS
アロケーションユニットサイズ 4096
SMR HDD
IOデータ製外付けHDD(ドライブ：ST4000DM004)
NTFS
アロケーションユニットサイズ 4096
PCとの接続
USB3.0
コピーツール
IOデータマッハCOPY >>63
最初の1回だけ時間がかかるのなら良いんですけど、自分の場合は毎回この作業が発生します。
撮影後は毎回データを転送します。その所要時間が毎回今の2倍かかるわけです。 >>66
ちなみにデータの転送元はXQDカードで、カードリーダはSONY MRW-E90。
データの転送速度は
SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)
140MB/s前後
SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
今回のテストで見てた感じだと、36MB/s から 120MB/s程度で平均すると70MB/sくらい 保証はできないけどアロケーションユニットサイズ６４ｋで改善しそうな気がするな >コピーツール
>IOデータマッハCOPY
あっ・・・（察し） >>71
FastCOPY使った方が良い？
とりあえずマッハCOPYで困ってないからそのまま使ってるけど。 フォーマット直後のまっさらなHDDにただシーケンシャルにデータを書き込んでいくだけだから、
CMRでもSMRでもたいして変わらないんじゃないかなと期待してたけど、実際はそうでも無かった。
それともCMRかSMRかってこと以前に、単にIOデータ製外付けHDD(ドライブ：ST4000DM004)が
しょぼいだけ？ >>72
マッハコピーはWin10だとメモリー相性最悪で公開終了予定だがデータ化けとか大丈夫か？？ 外付けだとSATA-USB変換基板の処理能力の差があるかもしれない
ただそれがどこまで影響大きいのかは分からない >>74
そうなんだ、それはありがとう。
そう言えばOSの事を書き忘れてた。
別にWin10 PCもあるけど、この作業に使ってるのはWin7 PCです。
Win10 PCでマッハCOPYを使ったことも何度かあるけど、データ化けは無かったです。
ただ転送速度はWin7 PCほどは出なかったです。 >>76
68です。
今はWD青6TBを使ってますけど、以前は同じIOデータ製の外付け4TB HDD(ドライブ：WD CMR)を
使用していて、転送速度は今のWD青6TBとほぼ同じでした。なので、IOデータ製外付けHDDの
SATA-USB変換の処理に問題があるとは考えにくいかと思います。
ただ条件を同じにするためにも、SMRの方も殻割りまたは別途購入をしてWD青と同じHDDケースに
入れてテストすることは、いずれやってみたいです。
あとはコピーツールをFastcopyにしてみますかね。 >>73
フォーマット直後のまっさらなHDDにただシーケンシャルにデータを書き込んでいくだけでも
SMRだと瓦の書き換えの処理とかが発生してるんですかね？
実際このSMR HDDのCDMは、テストサイズ50MBでSequential Writeが111MB/sしか出てな
いです。ST4000DM004の実力ってこんなもん？ それとも何か他の問題を抱えてますかね？ >>79
今の外付けHDDのUSB3.0接続の限界がだいたいそのくらい
M/BによってはUSB接続数で帯域が持ってかれる（接続してるだけで）から100MB/s出れば高速な部類 さすがにUSB接続はないでしょ、それじゃどっかの収集家だぜ >>79
スライディング裸族でST4000DM004使ってるけど、速い部分で大きなファイルを書き込むと190MB/s位出てるよ。
50MBのように小さなファイルを扱うとSMRのオーバーヘッドでパフォーマンス出ないんでは？と思う。 >>67
これは失礼した
毎回>>60の転送量が発生する訳ね
ならもうCMR買うしかないね
NAS用でなくてもWD青はまだ一部しかSMR採用でないし、東芝のMD04、MD05は全部CMR >>83
いえ、失礼ということは無いです。
私も説明が足りないので。
WD青6TBがCMRのままでこの先も入手可能であればそれが一番ありがたい。
ただ青2TBがSMR化されてるので、6TBのSMR化も時間の問題かと？
東芝は守備範囲外なので調べてみます。 >>80
>>82
CMR、SMR双方について、テストサイズを変えたりしながらベンチを
取り直してみます。 DOSVレポート1月校のあの擁護記事は一体何だったんだ？
＞「もしかして･･････SMR!?」
＞最新2TBプラッタHDDをとことんイジメる。 >>86
https://pc.watch.impress.co.jp/docs/news/1156085.html
ネットの論客にファイナルアンサー! ～「もしかして……SMR!」。最新2TBプラッタHDDをとことんイジメる - PC Watch
ですね。
ランダムライトはTxBENCHを使ってますが、シーケンシャルもTxBENCHですかね？
これを使えば、記事と同じようなテストが出来るんですかね。 >>85
テストするならエクスプローラのコピー機能でやってね。
野良ツールでテストってオマ環だからね。論外。 >>89
Win7とWin10ではバッファ周りが違うよな
むしろ野良呼ばわりされるツールのほうが公平
fastcopyとかでいいんじゃ
>>78でこれを使うと言っている > むしろ野良呼ばわりされるツールのほうが公平
そうかなあ。win7の時代はSMRは机上でしょ。長年CMR HDDでチューニングされてきた
歴史ある野良ソフトが、SMR HDD 使用ではダムンということもあるんじゃないの？ 知らんけど。 今日のテスト結果
すべて使用PCはWin7 64bitです。
[1] CDMを最新版にしてベンチ再測定
SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
テストサイズ 50MiB
Seq.Write 73MB/s
テストサイズ 1GiB
Seq.Write 150MB/s
CMR WD青6TB(HDDケースで外付け)
テストサイズ 50MiB
Seq.Write 171MB/s
テストサイズ 1GiB
Seq.Write 184MB/s
SMRもCMRもテストサイズが大きい方がSeq.Writeが速くなる。
CMRではその差はわずかだけど、SMRでは大きく違う。 [2] Fastcopy：121GBのデータ(XQD)のコピーの所要時間
Fastcopy
Buffer 256MB
SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
転送速度 85MiB/s
所要時間 24min41sec(1481sec)
SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)
転送速度 134MiB/s
所要時間 15min30sec(930sec)
参考
マッハCopy(Ver.1.00)
SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
所要時間 31min50min
SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)
所要時間 15min30sec
FastcopyでもマッハCopyでも、CMRへのコピーの方が速い。
CMRへのコピーならFastcopyとマッハCopyの所要時間はほぼ同じ
SMRへのコピーではFastcopyの方がマッハCopyより速い。
Fastcopyでは、SMRへのコピーの所要時間はCMRの1.6倍。 FastcopyではSMRへのコピーの所要時間はCMRの1.6倍ということで、マッハCopyを使った時の
2倍からは改善したけど、CMRとの差をもっとつめる方法は無いかな？ >>93
面白そうだったので下記条件で同じようなテストしてみた。
ソースファイル : 23MBの動画データを 単品、2本合成(46MB)、4本合成(92MB) で複製を多数用意
ソースフォルダ: 23MB 880本、46MB 500本 92MB 320本 の3フォルダを用意。
ソースHDD ： ST8000AS0002 使用率99z 空きエリア41GB
ソースHDDケース トランセンド (8TB市販品無改造)
コピー先HDD ： ST4000DM004 49％使用
コピー先HDDケース ： IOデータ (USB外付3.0 取り外し流用品)
コピーツール ： fastcopy 3.6.1 buffer size 256MB
pc : dell ノート core I7 第三世代 、Windows 10
■最終転送速度 23MB 91.1MB/s. 46MB 111.2MB/s 92MB 120.2MB/s
ソースファイル、コピー後ファイル の断片化はなし。 ソースHDDの状態は最悪。
上記の転送速度の差異は主にヘッドシーク回数の多寡が原因と思われる。
新品のHDD同士であればコピー速度はもっと改善できると思われる。
>>93 については、>>95 の提言がおススメ。 >>95-96
じゃ、次はWin10 PCの方でテストしてみます。
テストするたびにゴミがたまっていくので、またフォーマットかけてまっさらにしたいんだけど、
この場合ってクイックフォーマットで大丈夫？ Seagateの瓦たくさん持ってるが、バックアップでげんなりしている。
普通に使う分には問題ないけど。
瓦はやっぱり安いし、我慢してたが、やっぱもう無理。
そこで8TBの非瓦を探してるんだけど、安いのってどれ？ 最初のバックアップ作業が地雷になるんだから、店側も注意喚起すべきだろ >>101
それはわかるんだけど、SMRって本当によくわからない。
そのあたりのサジェスチョンがあれば、と書き込んでみました。
今、SMRはそれぞれ単体で使っているけど、ググってもよくわからない
ことが多い。
1.ストライピングしたら速くなるのか 多分ならない。
2.SMR的技術にメーカー間の明確な特徴の違いあるのか
3.いったいどれがSMRなのか。
4.SMRでたとえば8TBモデルでバックアップとかするとき、速い方法はないか。
>>99の茶飲み話に付き合ってもらえると、そのあたり、なんか見えてくるかなあと。
でも、要するにSMRってちょっとずつデータをためていく用途でしか
使いにくい、ってことだよね。 >>97
メディアキャッシュをフラッシュさせる方法が不明だからなー >>97
>>103
Seatools USBでSanitizeすればメディアキャッシュもフラッシュされると思う
最初にガリガリシーク音がしてて、その後静かになる
なので最初にメディアキャッシュ消去、その後ゼロフィルみたいな動作してる感じ
時間も全域シーケンシャルライトでゼロフィルするより掛かる
WDみたいにTrimに対応してほしいものだ >>103
基本は放置。アイドリング。 連続コピー中でも、ソースファイル読み出し中とかで間が空くと
フラッシュを間歇的に行なっているみたいだね。フラッシュ中はHDDの状態はビジー表示。
パフォーマンスモニタでSMR HDD のビジー状態を監視すればフラッシュ動作中かどうかを
視覚的におおよその判別ができる。状態サンプリングはそこそこ大雑把。 パフォーマンスモニタの観察は結構面白い。
メディアキャッシュがオーバフローしなかった正常なランダム書き込みだと、
書き込み終了と同時にパフォーマンスモニターのビジー表示は0%に戻る。
オーバーフローしていた場合はビジーステータスは100%のままで1分間程度推移。
すぐさまゼロ表示には戻らない。この状態でコピー継続すると速度は1MB/s前後。低速。
コピーの終了停止後しばらくするとステータスは心電図的な山谷表示になる、
コピー速度も上がるがコピー再開しても簡単にオーバーフロー状態に戻ることがあら。
メディアキャッシュが全フラッシュされ空でかつHDDがアイドルしていればビジーは0%表示。
シーケンシャルコピー時は ビジーステータスは50%程度の直線表示。台形水平線的な表示。
シーケンシャルコピー中でもHDD上の空き断片に遭遇したり小さ過ぎるファイルコピーとかで
メディアキャッシュの残存率が埋め下がるとビジーステータスは100%へと右上がりする。 意図的にアイドルタイムを設けるコピーツールとか誰も作らんだろな ベンチマークやっても実際のSMR領域ではなくメディアキャッシュ領域の結果が出るから意味ないんだよなこれが >>108
それが本来の使い方だろう
わざわざキャッシュ漏れの結果を知ったところで使用上は意味がない >>99
瓦と非瓦とまぜてバックアップするのはいいかもな。
通常使用は瓦で徐々にデータを貯めていき、一括バックアップのときは非瓦に。
瓦をバックアップに使うときはリアルタイムバックアップで。
これでデータが3セットできるからだいたい大丈夫だろう。 >>108
そうね。SMRはランダム書き込みが遅いとかいう風説は小さな勘違いがあるんだよなあ。
アレは実はメディアキャッシュのフラッシュ方式の遅速の問題に過ぎず、
SMRの瓦バンドそれ自体のデータ転送能力のことじゃないんだよね～
Seagate disks are known to clean during idle times and to have static mapping [1].
Therefore, they have high throughput while the persistent cache is not full, and ultra-low
throughput after it fills. The difference in the time when the throughput drops suggests that
the persistent cache size varies among the disks. Western Digital disks, on the other hand, are
likely to clean constantly and have dynamic mapping [9]. Therefore, they have lower throughput
than Seagate disks while the persistent cache is not full, but higher throughput after it fills.
https://www.usenix.org/system/files/conference/fast17/fast17-aghayev.pdf
海門のメディアキャッシュは静的マッピングで、フラッシュはアイドル時なのでランダム書き込みは
キャッシュがオーバーフローする迄は高速。オーバフロー後は劇遅い。
対してWDのメディアキャッシュはダイナミックマッピングでフラッシュは随時。ホストPCが連続書き込み
sている場合でも随時瓦バンドに吐き出し続けるので海門比較では通常時の書き込み速度は遅い。
しかしオーバーフロー後でも劇遅にはならない。
ちなみに、ST8000AS0002の瓦バンドサイズは30MBメディアキャッシュはおよそ25GB。 ↑論文で挙げられているWDのSMR HDDは WD40NMZW 2.5inch 4TB。 >>102
4に関しては初期のSMRのドライブでないなら、小さなファイルの大量書き込みを避ける。(初期のSMRドライブは何でもメディアキャッシュに書き込むドライブもあるらしい。そういうドライブは工夫でどうにもならんと思う。)
具体的には圧縮ソフトでも使って、大きな一ファイルにしてしまえば良い。
圧縮ソフトのtempフォルダをSMRドライブ以外に設定する。（圧縮済みファイルを編集する時） 今日のテスト結果
今回はWin10 PCでやりました。
[3] CDMによるベンチ測定
OS:Windows 10 pro 64bit
SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
テストサイズ 50MiB
Seq.Write 118MB/s (ばらつきが大きい)
テストサイズ 1GiB
Seq.Write 174MB/s
CMR WD青6TB(HDDケースで外付け)
テストサイズ 50MiB
Seq.Write 258MB/s
テストサイズ 1GiB
Seq.Write 158MB/s
CMRのテストサイズ50MiBで、Seq.Write 258MB/sという結果が出たけどこれは何？
これがWin10の力？ [4] Fastcopyで121GBのデータのコピー実施
OS:Windows 10 pro 64bit
ソース：約20MBのファイルがおよそ6200個 合計121GB
Fastcopyで121GBのデータのコピー実施
Buffer 256MB
SONY MRW-E90(XQD) → SMR IOデータ製外付けHDD(ドライブ：ST4000DM004)
転送速度 99MiB/s
所要時間 21min00sec
SONY MRW-E90(XQD) → CMR WD青6TB(HDDケースで外付け)
転送速度 122MiB/s
所要時間 17min04sec
Win7での結果に比べると、SMRは所要時間が短くなったけど、CMRは逆に長くなっちゃった。 今、Win10 PCを使って、Fastcopyで121GBのデータのコピー(対 CMR)を、コピーツールを使わずに
標準のコピーで実効中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。
Win10 PCで対CMR HDDならコピーツール不要ってことか。
テストサイズ50MiBでSeq.Write 258MB/sという値は伊達じゃないってわけか。
対SMR HDDだとどうなんだろう？ [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の差ですね。
あとはディスクの内周まで書き込みが進んだ場合にどういう挙動になるかですね。 >>116
> 今、Win10 PCを使って、Fastcopyで121GBのデータのコピー(対 CMR)を、コピーツールを使わずに
> 標準のコピーで実効中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。
コピペで日本語がおかしいので、訂正。
今、Win10 PCを使って、121GBのデータのコピー(対 CMR)を、コピーツールを使わずに標準のコピー
で実行中だけど、これが一番速いな。転送速度は安定して150MB/s前後出てる。 >>115
バッファがデカすぎじゃね？
256MBってなんか根拠あるの？？ fastcopyのバッファを変化させたデータも取ったほうがいいんじゃ？
256MBを32MBに落とすとか512MBにするとか StoreMIとSMRのHDD合わせると調子よかったりするのかな？ >>3
記憶域プールのパリティ書き込みは瓦じゃなくてもそれくらい遅いぞ >>126
ホントだ基本的な比較もしてない
>>3はひっどい記事だな SMRっぽい6TBの型番が判明したころからそうだったけど >>106
>HDD上の空き断片に遭遇したり
これが問題なんだよなぁ。使い込むに従って断片は増えていくわけで。
あれ？メディアキャシュフラッシュする時って、以下のどっち？
1.可能な限りブロックそのまま吐き出す
→シーケンシャルに吐き出せる。そのブロックが本来の場所になるようにする。
2.本来書くべき場所に吐く→吐き出し時にランダムアクセス多発？
1だと断片化がえげつなくなりそうだし、2だと、フラッシュが長くなる＆空き容量が減ると恐ろしや。
もっと上手くやる手段があると信じてるが… NAS用アイアンウルフですらPMRなのは10TBなんだな
お値段倍近い赤なんて無理だよ 鉄狼8TBはSMRでそれ以下の容量もSMRらしい
10TBはCMRだけどそれより上は知らない 〃´⌒ヽ
., -―― ﾒ／_´⌒ヽ
／ ／￣ ´ヽ ヽ
./ , /// ﾄ. ! ､ 丶ヽ
l / /（(（リ从 ﾘﾉ）） '
| i l ． ヽﾉ ．V l
l ,=! l /// ///l l ねんがんの１４ＴＢをてにいれたぞ！
l ヾ! ', l ヽ_フ l l
| ヽヽヽ //
l ヾ≧ , ＿_ , イ〃
li （´｀)l {ﾆ0ﾆ}､ |＿"＿＿＿
li /l, l└ ﾀl」／| ＨＤＤ |
ﾘヽ/ l l__ .／ |＿＿＿＿＿|
,/ L__[]っ ／ ( ⌒ ) ／
::::::::/ ヽ、 :: ::: ::: :::::::::::::::::::::::::::::::::
:::::/ lﾊ ::: : :: :::::::::: :::::::::::::::::::::::::::::
::::l l /ﾉﾘ ::: : :: ::::::::::: ::::::::::::::::::::::::
:::| /） / ::: : :: ::::::::: :::::::::::::::::::::::::::::
::l /ｲ/| . :. :. .:: : :: :: :::::::: : ::::::::::::::::
/ / ||/ /￣￣￣￣￣７l:::::::::::::::::::
i /_,／i! /⌒⌒⌒⌒⌒/ ,l::::::::::::::::
l 人 /⌒⌒⌒⌒⌒/ /::::::::::::::::
l / /⌒ヽ⌒⌒⌒⌒⌒/ /::::::::::::::::
l /iｌ | ） ⌒⌒⌒⌒/ /::::::::::::::::
ll l i! ｀ｰ、＼_＿＿＿_/ｎ/::::::::::::::::
lヽ l |＼. ＼ /⌒〉:::::::::::::::: ええええええIronWolf4TB買っちまったよおい
SMRなのか！！！！！！ぎゃああえいういのりま」るそらこやそこたねふこえかとゆそほ 調べてみたけど本当ぽいね
IronWolf←SMR(8T以下) 本当にうざいわ
HDD買う時にイチイチSMRかどうか確認すんのメンドウなんだよ
しかも開示してないから分からねーし 古いモデルをまだ売ってるうちに買い溜めしておけってことなのかね
WD青6TBぽちぽちぽちぽちぽちぽち…… >>140
…と思ったが、確定的な情報じゃなかったわ
すまん
ちなみにSMRと断言してるレビューが幾つかあったのは確認してる メディアキャッシュ搭載とごっちゃになってるだけじゃないの？ キャッシュ容量が128とか256だからSMRってわけじゃないぞ？
最近の大容量モデルはキャッシュ増やす傾向
だから余計わかりにくい …かもしれない
8Tと10Tで挙動が違うのは事実(他のモデルは不明)
8Tに大容量連続書き込みを行うと、例のArchive HDDと同じ挙動(メディアキャッシュ搭載だと同じになるかも?)
ただし、10Tでは速度低下は起きない(これがよく分からないが10TがCMRなのは確定してる)
なので、現状は鉄狼の8Tはあやしいとしか言えないか… キャッシュだけで判断するのは愚かだと昔から言われてんだろ
CMRのIronwolfもプラッタ上にメディアキャッシュは搭載されてる
メディアキャッシュに書き込んでるときの速度と比較して多少遅いくらいならSMRじゃないと思うが
速度低下とやらがどれくらいの値なのかを教えてほしい >>132
> 使い込むに従って断片は増えていくわけで。
この正月休みに、ノートPCにつなげてある外付HDDを10台を全台デフラグしたんだが
デフラグはするもんだなあ。Windows 10のエクスプローラで外付間のファイルコピーのほとんどが
110MB/s 以上コンスタントに出るようになった。コピー後の生成ファイルの99%が断片ゼロ。
使用率99%51GBや使用率95%の8TBのAS0002やかつて断片60万個以上あった4000DM002でも。
Windows10のエクスプローラはファイルコピーの際に、可能な限り断片を作らないように空き地を
確保するファイルアロケーションで実行動作している。ある糞ツールは5GBのファイル1個生成する際
2万個以上の断片をオニギリして吐き出すにだが、そんなボロボロなファイルでさえエクスプローラは
フラグメント・ロンダリング、断片洗浄してキレイなファイルを精製するのよ。だからファイルコピーで
ディスク整理を頻繁に行なっても、実は断片は殆ど増えない。というのが俺の実感。 > あれ？メディアキャシュフラッシュする時って、以下のどっち？
> 1.可能な限りブロックそのまま吐き出す
> →シーケンシャルに吐き出せる。そのブロックが本来の場所になるようにする。
> 2.本来書くべき場所に吐く→吐き出し時にランダムアクセス多発？
これは 2 でしょ。あるデータブロックをどこに配置保存するかを決めるのはOSの仕事で
HDDのファームが勝手に恣意的に行う事はない。あるファイルがどこにどのように保存
されてあるかというファイル配置(ディレクトリ)情報は NTFSならHDDの外縁部の12.5%を占める
MFTに記録される。HDDがそれを自己都合で任意に書き換えたりはしない。だから、
フラッシュを行う際には大量のヘッドシークを伴うランダムカキコになるはずですね。
ただし、メディアキャッシュの在り処がHDDの最外縁部にありディレクトリ情報保存のMTFと
隣接しているためディレクトリ情報更新のヘッドシークは最小限になるはず。また最近の
WindowsはランダムアクセスをWindows自体の内部処理としてオンメモリで処理して、HDDの
ヘッドを省力するようなキャッシングをサポートしているので、処理の軽重はアプリ次第で
改善の余地はあるらしい。 >>150
鉄狼8Tのamazonや価格のレビュー見たら分かるが、100G超えの書き込みで三分の一以下に落ちるらしい
これをどう判断するか… >>153
うちはなんともない
つーか筐体見たら8TBは6プラであることはすぐに分かる
これをわざわざSMRにする理由が無い
ガセネタを広めるのはやめろ メディアキャッシュ領域とディスク内周のランダムライトなら3分の一くらい普通にありそうだけど・・・ シーケンシャルでも最外周と最内周で2倍違うのとか知らないじゃね
価格の情弱レビューだし >>153
4000DM004の ultra-low throughput after it fills は1/3なんて生易しいもんじゃないよ。
1/100～1/200以上。 120MB/s～ が 500KB/s ～ 2MB/sに落ちるし。
1/3 程度、つまり 30～50MB/s 程度で速度低下が収まっているのであれば、それは普通の現象。
コピー元のソースファイルの断片化が禿げし過ぎる場合はCMR／SMRに関係なく普通に生じる。
断片サイズが200～400KB以下の場合、5GBのファイルが万単位の断片断片のおにぎりの場合、
コピー速度は40MB/sを下回ることが多い。断片の数だけ読み出し時にヘッドシーク動作が挿入
されるからコピー速度が劇遅になるのは当然。CMRもSMRも同様。
対策としては、断片大量含量ファイル生成時に他ドライブへコピーするとかオンドライブでデフラグ。
或いはファイル整理時にエクスプローラで低速承知でコピーするとかで、断片洗浄する。
洗浄後無断片になれば、50-100MB以上のサイズがあればSMRで100MB/sを下回ることはほぼなくなる。 断片含有ファイルの断片洗浄ツールとしてみるとエクスプローラは優秀だと思う。
万単位の断片を含む糞ファイルでさえ断片洗浄し無断片な一本ファイルを精製する。
それに対して、Windows10のアップデーターは糞の類。Cドライブをデフラグした時
テンポラリ名を持つシステムファイル4本がシステムファイルであるがゆえに
書き換え拒否されデフラグ不能。それらはアップデートのたびにドライバーなどを結合統合した
起動イメージのスナップであろう。が数十以上の断片で構成。起動を遅くする原因を
Windows自らアップデート度に作っている。ように見える。 >>153
3分の1なら30MB/s,40MB/sとかか
SMRなら0MB/sまで落ちても不思議ではないので、CMRだろ
1.33TB×6枚プラッタだろうし、100GBとか移動したならおそらくメディアキャッシュ切れで速度低下したんだと思うけど
知ったかぶりが、速度低下したからSMRだ！とか書いてるだけだろ SMRの8TBとか一気に書き込むとどれくらい時間かかるんだろ
東芝8TBのCMRでもだいぶかかったけどそれの2-3倍かー >>168
だいぶ とか曖昧な表現をする奴に価値は無い >>170
Yahoo知恵遅れは昔っからの呼び名だよ >>152
メディアキャシュの時点で本来の場所以外に1クッション噛ませる仕組みがあるからとも考えたけど、やっぱり普通に考えて2だよなぁ
って事はフラッシュ時にあっちこっちのSMRブロックの読み書きが必要って事で…フラッシュ終了の期待時間ってどのぐらいなんだ？
メーカーはフラッシュのシミュレートデータ持ってるハズだから出してほしい…SMRすら言わないんだから無理かww そもそもメディアキャッシュの前にキャッシュに書いてるので2クッション 読み出しヘッダーと書き込みヘッダーを少しずらして配置して、
少し先を読み出しながら書き込むようにすればメディアキャッシュは不要なんじゃないかな？
ブロック内のちょっとした書き換えでも、SMRブロックを丸々一つ分書き込まないといけないのは変わらないけど。 HDDの大容量化に合わせてアロケーションユニットサイズも大きくすべきだろうが、
そうなるとクラスタギャップ分の損失がどれだけ出れるだろうか……
を知りたくて、それをシミュレートするためのツールを自作したっけ そりゃもちろんアロケーションユニットサイズ＝ＳＭＲブロックサイズにすべきでしょ >>174
昔の3ヘッドのカセットレコーダーのようだ >>174
SMRブロックサイズ未満のデータを貯めておくところが必要だし、
一部書き換えのデータが連続で来た場合に
SMRブロック更新を順番に行いながらデータ転送を受け入れるような
とても遅いドライブになると思うが。
同時にヘッド動作させるなら読み出したいトラックの位置と書き込みたいトラックの位置それぞれに
微調整しないといけないのにヘッドアーム1つじゃどうしようもない。 そういえばSMRのHDDの故障しやすい問題はファームウエアで完全に直ったのかな？
故障しにくいHDDはHGST安定なのは相変わらずのようだ、うちのHGST HDS5C4040ALE630も
46000時間越えが2台あるが、まだ壊れそうな気配すらない。
http://gigazine.net/news/20181017-backblaze-hdd-stats-q3-2018/ >>178
----------------------------------------------------------------------------
(2) ST2000LM007-1R8174
----------------------------------------------------------------------------
Model : ST2000LM007-1R8174
Firmware : SBC1
Serial Number : ********
Disk Size : 2000.3 GB (8.4/137.4/2000.3/2000.3)
中略
-- IDENTIFY_DEVICE ---------------------------------------------------------
中略
060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0100 >>179
SMRは本質的に遅いだから、見た目の書き込み速度を稼ぐにはフラッシュ時のペナルティやベリファイのやりにくさを受け入れメディアキャッシュを使用するしかない
JVMのメモリ同様キャッシュは大きければ大きいほど良いのではなく、サイズや吐き出しタイミングのバランス等はメーカーの腕の見せ所で、是非宣伝材料にしてほしいが…
ところでSMRってドレだっけww 一般的な家庭用録画機、TVの外付けならスペック的に無問題。
24時間全録な録画用、リニア編集なプロ用とかなら、鉄狼や赤色
みたいなNASスペックが必須かも。 シーゲイトのPR記事では複数ストリームの同時記録みたいなことは苦手って言ってなかったっけ？
だからレコーダーの2番組同時記録とかするのならSMRは止めたほうが良い。
乗せるのならAVコマンド対応のドライブ。
WDのAV-GPや紫、東芝の末尾Vシリーズ、シーゲイトのSkyHawkなど どっちがデマなのかわからん？
3番組録画出来るの？出来ないの？ シーゲートの人がSMRは同時録画用途には不向きと記事で言ってたのは見たことある AVコマンド対応ドライブがみんな非SMRなことから考えてみれば、答えは出てると思うけどね。 まだSMRを表に出してた頃の記事だけど
https://akiba-pc.watch.impress.co.jp/docs/sp/680650.html
普通のTV録画用として使う分には問題ありませんが、多数のストリームを常時同時に録画する、という用途には向いていないかもしれません。
今の世代のSMRでここが改善されてると思えば使えばいいんじゃないかな。
今のSMRはいろいろと別モノだと思うし改善されてる可能性もあるとは思うけれど、
録画失敗のリスクと価格メリットを考えてどっちを取るかだと思うよ。
自分で判断できないのならテレビやレコのメーカー推奨ドライブ買うしかない。 同時録画はAVコマンドが無いCMRの青でも
うまくいかなかったりするよ
SMRの方が遅いなら難しいんじゃね >>194
１時間録画してインターバルが数時間ある。そして２～３番組録画をしないって条件ならSMR処理が間に合いそうだけど、
そんな気を使うレコーダーなんてイヤだw >>192
その記事は5年前のだね。
海門の正規代理店やってるエレコムがパッケージングして量販店に出している4TB、
初期ロットはDM005だったが最近のはDM004に変更されている。どっちも録画用で
4K、スターチャネル録画などで使用している。2番組同時録画もするが無問題ね。
最近のregza は6TBサポートが公式。当然SMR HDD 対応でしょうねえ。
Seagate 3年保証 4TB TV 録画 外付 HDD 4K テレビ PS4 対応 静音 ハードディスク 3.5 インチ USB3.0 シーゲイト 日本正規代理店品 安心コールサポートあり
https://www.amazon.co.jp//dp/B07FN69HLW >>183
ドライブ側の遅延でリアルタイム録画の書き込みが追いつかなくなった場合に、レコーダー側がどう対処反応するかが不明
録画を停止するか、壊れるか
一度内蔵HDDにでも録画した番組を外付けSMRHDDへダビングして保管するなら、リアルタイム性は要求されないので問題ないように思われる >>186
あのPR記事は、たったの24時間の録画しか検証してないから
まだ容量が膨大にたくさん残ってる状態で検証しても、SMRドライブの動作傾向を知るのになんの参考にもならない >>198
SSDじゃないから残り容量なんて関係ないんだよなあ >>200
ガベージコレクションの関係で空容量は関係あるだろう >>200
膨大な連続空き領域が残っている状態での検証で、フラグメントが分散している状態で発生するSMR特有の挙動が解かるわけないだろ >>204
録画機のHDDがOS無縁で勝手にガベコレするわけ？ ガチ無知さん乙w >>フラグメントが分散している状態で発生するSMR特有の挙動
どういう挙動なのさ？ >>205
ドライブマネージメントってそういうものでしょ。ホストマネージメントなら勝手に動きはしないけど。 >>206
フラグメント分散している箇所のSMRブロックでの読み出し→マージ→書き込みの繰り返し動作のことだよ、SMRドライブ特有の >>208
そういうランダムアクセス時の読み出しマージ上書きはCMRでも頻繁に起きるよね。
あるファイルの先頭からXXXバイト先のデータyyyバイト上書きするような場合。
新規録画とか、ファイルコピーとかではそもそも同一ファイル内で上書きは行わない。
シーケンシャルなファイルを新規作成するだけ。上書きコピーは新規ファイル作成後に
旧ファイルを削除するだけでしょ。 >>207
ドライブマネージドなHDDがセルフで勝手にガベコレするって？
第五回。そういうものじゃないよw >>168
2-3倍なんてほどにはかからんよ、という回答でいいか？
AS0002で300MB程度のファイル8TB分のコピー何度かやってるが
定期的に息切れして超休憩しやがるだけだからね
読み出し側の断片化もあるから
平均すりゃまあ70MB/secくらいかね？24時間は超える。
読み書き共にminiSAS経由のSATA接続、linuxでcp -dpR実施なので
Win10ならもう少し早いのかもね。 >>210
あなたはどの部位のガベコレかを理解できてないですね >>212
この人もか
どの部位のガベージコレクションか理解できてます？ >>210
GCはドライブ側が勝手にするものだ
そうでなければどのホスト(PC/レコーダー)でも使えるHDDとは言えないだろ うちはパナソニックのレコーダだからAVコマンド対応のHDDじゃないと録画がうまくいかない場合が多いので
SMRが対応していればいいが対応していないものばかりだから、普通に東芝かWDのAVコマンド対応HDD使ってる。 >>214
海門のはメディアキャッシュ上でガベコレなんかしないようですよ。
あそこでガベコレする暇があればフラッシュして解放した方がよい。
というスタティックアロケーション方式だそうですから。WDは別ですがね。
ま、RAMキャッシュ上なら256バイトもあるからやるかもですがw
>>216
ガベコレしちゃうドライブマネージドなHDDって。どんなガベコレするの？ メリットは？
妄想じゃなければ、リファレンスソースもよろピクね。 >>217
DIGAのアレは都市伝説？ パナの外付けUSBの担当技術者Gは技術力が低くてバギー
というだけじゃないの？ うちでも火狐OSのパナの4KにエレコムのWDな4TBつなげたら録画で
エラーしまくり。アイオの4TBに変更したらとりあえず問題は起きなくなったとかの不具合。
我が家でも経験あるし。他にも3TB制限とかhubサポート無しとか。人づてでわパナの4Kチューナーは
録画サポートがバージョンアップ対応だったが、昨年末の紅白に間に合わなかったそうだし。 ﾜｯﾁｮｲ 11c5-sj7P は、要するにからかってるだけの無意味なヤツなので無視して良いんじゃね？
このスレでの定見としては、各社のHDDにSMRなら明記して欲しいってだけだし。 PC関連スレによくいる荒らしのスロットルおじさんだろこいつ おちつけ
SMR固有のGCがあるかは良くわからんが 論理的には>>204 とか有るわな。
で
自動GCがあろうが無かろうが 汚れ具合・空き要領が少ないと連続書き込みになら無い場合の影響はSMRの方が論理的に大きくなるのは自明かつ、SMRブロックとしての汚れはSMR固有なんで、ソモソモの検証が甘いと言う>>203の主張自体はオカシク無いよな。
つーかGC無い方が被害大きいと思うのは俺だけか？ >>204の元記事はこれ
https://akiba-pc.watch.impress.co.jp/docs/news/news/1024968.html
メーカーの人間の話ではない
現在採用されている技術か将来予想か不明
容量を犠牲にSMRブロック全体の書き換え頻度を減らす技術
SMRブロック内で論理セクタアドレスと物理セクタアドレスを切り離す
SMRブロックサイズに余裕を設ける
同一論理セクタアドレスに対する書き込みはブロック末尾に追記
論理物理セクタアドレスの対応を書き換える
この場合GCはSMRブロック全体？の読み出し圧縮書き戻し
SMRブロック頭に長寿命セクタを集めGCは途中からかもしれない
圧縮では同一論理セクタアドレスの古いデータが捨てられる
TRIM対応ならそこも圧縮
OSから見える空き容量とGC頻度はあまり関係ない
TRIM対応ドライブで採用すればランダムライトがCMRなみに出来るかもね >>221
外付けHDDケースの相性も関係するけれど
うちでは購入したパナソニックのCATVのSTBで、もし故障した場合に備えて内蔵HDDの
換装したことがあり、内蔵HDDの場合はAVコマンドなしのHDDはクローンして全初期化しても
録画したら真っ黒な画面で映像が出なかったので、対応品がいいのは間違いないと思う。
その後AVコマンド対応のHDDをクローンして初期化したら問題なく利用できたから。 >>229
ナルホドですね、thx。 サルベージ屋さんの視点で見ると面白いですねー。
たぶん、それって、WDのWD40 NMZW みたいなSMRのことじゃないかな。
WDのSMRはダイナミックアロケーションだという話だから。SMR瓦バンド内の追記って
WDの場合は4Kブロック単位で可能なのかな。というかバンド内のブロックの
チェインリンクが込み絡んでいると、HDDが壊れてセクタ単位でベアでデータ読んで解析するの
無茶苦茶大変かも。サルベージ屋さんからすれば困ったチャン認定なのだろうね。
ファイルサルベージの難度という観点から言えば、海門のラクダSMRはセクタ配置が
インクリメンタル・シーケンシャルだからいざという時でもEaseUSみたいなサルベージソフトが
普通に使える。WDのSMRだとそうはいかない。みたいね。 >>232
録画機内蔵HDDの換装は基本は同型番製品で交換ですよね。アプグレ狙いとかすると
メーカーのナゾナゾを試行で読み解かなくちゃならない。デバイスIDで換装プロテクトして
いるばあいもあるし。特に注意しなくちゃいけないのはHDDの消費電力。今時のHDDは
せいぜい数ワットだから無問題かもだけど、昔RD-X5のHDDを海門にしたら数ヶ月で
電源の12vが死んでご臨終。まあ、自己責任のスレ違い話でスマソ アーカイブ用途を前面に押し出さなくなった今のSMRなら
多少の容量犠牲にして使い勝手向上するのならアリじゃね？
現状ですでに容量に全力振りじゃない感あるし。 使い勝手に振るならどう考えてもCMRの方が良い
わざわざ面倒くさい仕組み作ってコスト上がって、安くもなく容量が多いわけでもない
SMRになる可能性が極めて高い それこそなんのために瓦開発したの、になる 瓦バンド自体は、容量が2割増し程度だろ
5割増くらいいかんもんかねー
精度上がってだめかね CMR 1.33TBプラッタがSMR 2TBプラッタに化けてるんじゃないの？ CMRプラッタは最大1.8TBまでいける。
またSMR化は容量アップというよりはプラッタ数削減によるコストダウンととらえるべき。
そのくせ市場に出回ってるSMR HDDはCMRに比べてたいして安くないのが問題。 そらメーカーにとっては枚数減らして既存品と似たような価格で売れるから、
海門以外もSMRを出して競争しない限り安くはならんわな >>240
5プラッタCMR9TBを安く出してプリーズ デスクトップ用の安価ラインには1.33TBプラッタ世代までのモデルしか出てない以上、
CMRで1.8TBがある言われても無意味だな。 WD Blue 6TB （WD60EZRZ）はCMRってことでいいんだよな？
型番がEZAZになるとSMRってことだよね？
いまのところBlue 2TBだけSMRなんだよな？
しかしSMRって容量当たり単価全然安くないよな 瓦8TB買ってこれはこれで倉庫用にいいなとは思うんだが
やっぱCMRの10TB安くなんねえかなｗ 巨額な開発費も回収したいだろうし極端な値下げはしないだろうね。
値下げ要因としてのSSDには期待してる。 seagate「HDD容量1TBでもよろしいですか」 瓦「メディアキャッシュをフラッシュするタイミングが来ないんだが」 >>195
録画終了してすぐにHDDへの電力供給が止まるんじゃない？
だとすると処理している余裕は無いかも？？？
SMR対応のレコーダーのアルゴリズムとして本体スリープ状態でも
しばらくの間HDD電源を落とさないようになったりしてな 内蔵なら茂ドライブマネージドでもフラッシュはするでしょうよ
外付けだと省電力が要らんことしいな気がする ハイエンドSSDのように巨大キャッシュを載せて来たりとかな
価格を考えれば何しても許されそう サンディスクってWD傘下なんだよね？
なんだかんだ言ってHD製造ってめちゃくちゃ儲かってるってこと？ HDDがオワコンだからいつやめても良いようにフラッシュメモリに手を出したんでしょ 2019年はSMR躍進の年
ソース
http://eetimes.jp/ee/articles/1809/25/news012.html
>一部のデータセンターはホストシステム側の改修が始まっており、
2019年以降にSMR方式が本格的に普及する見込みです。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>東芝では、CMR方式のHDDと並行して、SMR方式のHDDの開発も行っており、
SMR方式が本格普及に合わせて、製品提供を行う計画になっています。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SMRはもう二千円くらい安くしろー
あと透過的※なのはいいけどSMRに合わせたfsなりツールなり必要！
>>257
サンは知らんけどフラッシュメモリ全般が安くなってるからなー
システムSSDには120GBあれば充分で、そうなると2，500円くらい
※ユーザーから見えない、気にする必要が（あまり）ない ホストの改修云々ってことは東芝もいよいよエンプラ用ホストマネージドSMRの展開か
もともとロードマップにあったから驚きは無いけれど。
デスクトップ用3.5インチドライブマネージドSMRの導入も近いかな？
SMRの制御タイプにHA型なんてのもあるようだけど、
ドライブマネージドでもメディアキャッシュのフラッシュをホストから明示的に行ったり、
溢れたときにちょっと待って的なやり取りが出来るようになるだけでだいぶ使いやすくなる気がするんだけど。 ストレージシステムとして考えたらHDDもSSDも
それ単体よりも組み合わせたほうがより効果的に運用できるしね。
両方やってる東芝はもとより、サムスンと提携発表(2011年)したシーゲイトに後れを取るわけにはいかないしね。 寒村ロゴ入りのST-2000LM003 の稼働時間が25000時間超えたのでFireCuda ST2000LX001
に交換した。SSHDとはいえSMR。引っ越しはEaseUS todo backup。所要時間は10時間10分。
クロダチとかだと1TBの物理コピーが2時間半程度で済むので倍くらい余分に掛かった感じ。
SSHDなんで直近直前に起動したアプリの再度起動はそこそこ速いね。↓はオマケ。
あそこでは東芝・WDは相変わらずアレですなあ。
HDD故障率のメーカー・モデル別統計データ2018年版、故障率が最も高かったのは？ 19/01/23
https://gigazine.net/news/20190123-backblaze-hard-drive-stats-2018/ Win10はReFS採用しろよな
クソドライブだけ普及させても無意味だろうが >>265
まあそうでしょうね。たぶんリードアフターライトなご丁寧なチェックやっていたんだと思う。
メディキャッシュのオーバフロー原因の遅速なら100倍時間かかっても不思議ないし。
古い2TBはポータブルな第3倉庫利用するつもり。 OSの空きメモリに余裕があるなら、
SMR-HDDのメディアキャッシュ領域的なのは、OSのメモリ上に置いて、
SMR-HDDのメディアキャッシュを使わないほうが効率的だと思う
メディアキャッシュ領域を使う場合、いったんメディアキャッシュに書き込んで、
また読み出して瓦領域に書き込むっていう三度手間になるからな
OSがSMR-HDDを検出した場合、メモリに余裕があれば、
HDDの書き込みはいったんRAMに貯めておいて、
メディアキャッシュ領域をつかわない直接書き込みをしたほうがいい >>267
確かにそれだと効率は良いかもしれないけど、ファイルコピーや移動中に突然ブレーカーが落ちて電源切れたらデータ飛んじゃうんじゃない？ >>1の大容量HDDを100KB前後の画像だけで埋めつくす！！
まさに漢の利用法！！ >>267
Windowsはランダムファイルのオンメモリ処理をAPIでサポートしているよ。
アプリケーションがメモリマップトファイル・アクセスを実装していればOK
メモリ マップト ファイル
https://docs.microsoft.com/ja-jp/dotnet/standard/io/memory-mapped-files
>>269
UPS使えよ。
>>270
100KB前後の画像ファイルといえば大昔の100万画素以下のデジカメか古いガラ携の画像かなあ。
4TBを埋めるためにはおよそ四千万本。それはきっと壮大なコレクションですねえ。
メディアキャッシュ・オーバーフローの閾値は30G前後らしいから。コピー中にメディアキャッシュを
でオーバーフローさせて超低速を出現させて楽しむためには100KBの画像ファイルなら最低でも30万本は
必要だろうね。小さなファイルは読み出しに時間が掛かるから現実的にはもっとたくさん。 俺のエロ画像フォルダには35万個で180GBだった 不要なファイルを削除したり、取り出して加工したりリネームしたりが面倒
使い慣れてるビューワーでは見れなかったりも 過去のエロ画像を再利用しすぎじゃろ
常に新しい刺激を求めるんや tarとかで固めてもインデクス付いてるわけで大した負荷じゃないし固めたほうがいい Irfanviewにzipを解凍しないで見るプラグインはあるのか
ずいぶん昔、それがなかったからIrfanviewを使わなかったよ 断片化で体感でわかるのは10000以上の超過断片時
アクセス時に明らかに遅くなる アドレス再配置の事が有るくらいで読み込みは悪くないと思うけどね。
同じ磁気記録密度のCMRより効率良いし。 なんか話がいろいろ混乱してるけど、実際にコピーをしてみてSMRへの書き込みを評価するなら、
読み出し側の状態にも注意しましょうねって話でしょ？
読み出し側のファイルが断片化していて、そもそも読み出し速度が遅くなってるだけなのを、SMR
の書き込みが遅いと評価しちゃダメだよ、と。 ドライブ容量の空きが減ってくると(使い込まれてくると)、
書き込みに際しても断片的な空きスペースに書くことになるからって話かと思ってた。 >>288
2TBのSMR-HDDとかすぐにフラグメンテーション発生しまくりになるんじゃね？ そのうち4TBも２プラのSMRが占拠することになるだろう
偶数TBのHDDはすべて2TB/枚のSMRプラッタになる アーカイブ専用ファイルシステムＳＭＲＦＳなんてのを開発すればいいのに >>289
エクスプローラのコピー機能で言えば、コピー後のファイルが断片オニギリになるのは
8TBHDDだと残り100GB切ってから。というか長大ファイルを丸々保存できるスペースが
残っている内は断片無し。細かな空き断片を紡いだリはしない。
8TBで空きエリア50GBにGB超のファイルを15本程度コピーしたら3／4程度が断片化してた。
ファイルあたりの断片は2～30個程度だった。 ここまで大容量になるとアロケーションユニットサイズ(クラスターサイズ)も64KBでフォーマットして使ってるわ
ただし1GB以上のファイルしか置かないという制限付けて >>294
空き容量がどれだけあろうと、ＮＴＦＳ圧縮でファイル保存すると数千もの断片化ファイルになる 前から疑問だったんだけど、
断片化のひどい状態のことをオニギリと言うようだけど、どういった経緯でそうなったの？
キーの選び方が悪いのか検索してもそれらしい内容が出てこないし。 デフラグ画面の断片化した四角がポツポツある状態がオニギリの海苔みたいなイメージとか勝手に想像してた。 windowsXPで使う場合、SMRのHDDは問題ありますか？ 小さな米粒（断片化したデータ）を大量に集めて固めて一つのおにぎり（ファイル）になっているさまを言ってるんじゃねえかな
ただ、おにぎりは本来そういうものだしそれで美味いんだから比喩としては下手ってのも分かる
ついでに言うと「断片化」で充分話が通るんだから比喩表現する必要性も低い >>301
そもそも2.2TB以上のドライブを認識できないだろ
アライメントもおかしいし XPが主流だった時代はHDDも80GBが最大容量だったし 7以上のOSでフォーマットしてから持ってくれば一応ズレは直る
でも2Tまでしか使えないならSMR使う意味ないな SMRのブロックって256MBで確定なのか？
個人のブログ程度のソースしか見当たらなかったけど
ただ機構を考えるとキャッシュ目一杯のそのサイズで考えるのが妥当とも思えるが 普通に考えたらトラック単位でバンドブロックがあるだろうし、
トラックくあたりのセクタ数は一定ではない。
つまりバンドブロックサイズも一定ではないと考えるべきじゃね？ キャッシュサイズ目一杯はないと思う
コマンドキューが非順序実行用あるわけだから
リードライト複数ブロックキャッシュに乗らないといけない
ATAコマンドの最大転送量が３２MBなんで３２MBか１６MBか
16MB固定ブロックサイズとして最外周でも5周以上なんで最大ロスが20％全体ロスが10％
32MBなら全体ロスが10％
（シーク用の固定パターン除く） 訂正
誤 32MBなら全体ロスが10％
正 32MBなら全体ロスが5％
補足最大転送速度から１周容量3ＭＢ以下 >>308
1トラックのサイズって最外周でも3MB程度って事か？ >>303
それは昔の認識だね
今はツールでXPでも3TB以上のHDDが使えるよ
というかSeagateも公式ツールでXPに正式対応している
ただ、すべてを一つの領域は無理で、Seagateのは2TB+αに分かれてしまう（HGSTなら一つにできる） 空き容量が1GBぐらいになるまで埋めてからベンチマークすれば、違いが大きく出そうな気がする
買えないからテストできないけど いや俺がSMRのブロックサイズで思ってたのは
SMRのブロックを書く時って必ず瓦の層分のトラックを跨ぐシークが発生するわけだろ
例えば瓦3層1組で構成されてるSMRの場合は1ブロック書くのに必ず2回トラックを跨ぐシークが発生するわけで
そのシークを減らすために巨大なブロックが必要なのかと思ってたんだが
そもそも1トラックが3MB程度しかないなら瓦3層ならブロックは3*3の9MBあれば十分だな
もしかしたらSMRのブロックは書き込むトラックのサイズによって可変だったりする可能性もあるか？
瓦3層で書き込むトラックのサイズが1MBだったらブロックサイズは3MBより大きくある意味無いっしょ
他にブロックサイズを大きくする理由ある？ 螺旋書きだからブロック途中の非連続シークは発生しない
有効トラックがあるのは半径方向のせいぜい１/２まで
308で考慮し忘れたが重ねた部分はトラック密度が上がる >>316-317
螺旋でも隣り合った同心円でもバッファ働くから大差ないのでは >>318
書き込み遅すぎ
これはなんていうベンチ？ >>318
同じベンチをCMRの8TBにしたデータ無いですか？ >>318
ついでに同じベンチを8TBのSSDで行なった比較もきぼんぬ >>319
いやもしCMRが螺旋書き込みだったらブロック毎の書き込みにトラック移動のシークが
余計に発生するSMRはシーケンシャルライトでも完全劣化になるところだよ >>318
いくら倉庫用とはいっても最初にデータ書き込みする必要はあるわけで・・・
遅すぎでしょ。物売るってレベルじゃないわこれ >>301
そもそもXP使うこと自体に問題があるだろ >>320
Gnome Disks のベンチマーク
>>321
赤玉3Tが同じPCに刺さってるのでこちらを
https://i.imgur.com/Qc1oO0Y.png
>>322
無茶ゆーなｗ
>>324
ベンチはベンチ
通常利用ならきっとキャッシュが効くと思います >>326
ありがとうございます。
容量やメーカーの違いはあるけど、これがCMRとSMRの実力差と思って良いんですかね。 トラックが増えるからプラッタ当たりの密度は増えてるけどトラック密度は変わらんでしょ 書き込みした隣接のトラックも書き込まないといけない
↓
書き込んだ隣接トラックの隣接したトラックも書き込まないといけない
↓
書き込みした隣接のトラックも書き込まないといけない
↓
以下ループで1MB/s 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) シーケンシャルライト時に隣接トラックも書き込み対象にしてしまえば
隣接トラックに書きこむ処理をロスにはならなくできそうだけど
書き込み箇所はOSが決めるからそうは出来ないのかな？ >>331
LinuxのextNとWindowsのNTFSとではファイルの置き場所アロケーションのアルゴの態度が違うよね。
Linuxはアトランダム。NTFSは基本外縁部から連続的詰め込み。
>>326のGNOME DisksはubuntuとかのToolでしょ。Win/NTFS環境下のお話じゃないから窓的には
ちょっと筋が違うかもね。それとSMR@海門のバンドサイズは20～30MBだということだから(CM大論文)
テストファイルのサイズが10MBは、まあ弱点もろ突きかもねｗ
螺旋書き云々は、ま、書き込みヘッド幅が絶妙微妙なSMRではそんな面倒なヘッドシークしないよね。
螺旋書きを採用している外部記憶といえば旧MacOSのFDDが有名だけど、68KMacのエミュの作り手が
オリジナルFDD読み出しで苦労した点。結局特殊な同期ハードウェアを噛ますほかなかったとか。
あとはCDかな。螺旋読み込みがアクセス速度の頭打ちネックになっていたような。
Understanding the CD: The Spiral
https://electronics.howstuffworks.com/cd2.htm NTFSは1回の書き込みで5、6回書き込みが発生するからSMRと相性悪い
FAT系(exFATなど)で利用すると多少マシになる CDDVDのアクセス速度が遅いのはＣＬＶで回転数可変のため
螺旋配置とは無関係
連続アクセス前提ならスパイク状にシークして安定を待つより
一定微量シフトしつづけるほうが楽よ 微量シークだとトラッキング位置の調整は発生しないの？ いくら探してもSMRが螺旋記録って情報が見つからん。
知ってる人居たら教えてほしい ＷＤ使ってる人に聞きたいんだけど、インテリパークって無効にしてる？ 805 名前：Socket774 (ﾜｯﾁｮｲ df02-AYLp)[sage] 投稿日：2019/02/03(日) 12:52:37.28 ID:3EIz6RBR0 (PC)
WDの中の人と話せる機会があったからSMR化について聞いたら教えてくれたから報告
（プライベートでの内緒話とかじゃないやりとりです）
・2TBのSMRが出ました。4TBや6TBなど青は全部SMR化していくの？
→します。
・青が全部SMR化したあとは、CMRが欲しければ赤や黒を買うしかない？
→青以外もSMR化していきます。
・SMRかどうか判別のため、スペック表とかにSMRと明記された情報はないですか。
→現時点では、型番が「EZAZ」ならSMRで、他に識別できる公開情報はありません。 同業他社を買収して
独占的地位を得た後に
低性能なゴミを強制的に売りつけて
金儲けする
よくある話だね WDのSMRは特に評判を聞かないけれど、
シゲと同等と判断すべきなのか、シゲとは違って普通に使えてると判断して良いのか。 >>334
windowsseverしかフォーマット出来なかった気がするが10のアップデートでなんか変わったの? パーティション切ってテストするとよく分かるキャッシュの効能
内周部でも速度が落ちない 以下、何もかもうろ覚え！
>>335 >>337
螺旋書きは初耳だし怪しんでる
それは置いといてSMRもトラックあたりのセクタ数は光学ディスクのZCAV的な感じだったような
>>341
ここか前のスレにあった
キャッシュの吐き出しがチョロチョロ行われてて、茂よりやや遅いが急な速度低下はないという話 >>332
326のツールは知らんが、sda表示されてるからファイルシステム関係ないんじゃね？
>>315
1Gって何の話なんだか 将来的にはTDMRや多層記録がアシスト記録の次の技術ロードマップになってるし
ブロック書き込みが既定路線なのはわかるんだが、
問題はドライブマネージドのアルゴリズムやホストマネージドの普及展開。
NAS製品向けに安価なホストマネージド製品展開ってのはダメなのかな？ WDのSMRは試してみたいんだけど、さすがに2TBのドライブを今更買う気にならんしなぁ
まだファームの熟成段階なんかね。
6TBが予定に挙がってるようだけど、一気に10TBまで出しちゃえばいいのに。
10TBがTB単価2000円ちょっとで出たらがかなり魅力的なんだけど。
SMRの仕様を我慢してでも導入検討するわ >>332
シャープMZ-1200だったかに採用され、その後ファミコンのディスクシステムに採用された
片面容量64KBでディスク全体のシーケンシャルアクセスオンリーなクイックディスクが
螺旋トラックだった
CDランダム読み出しでのヘッド位置決めが難しいことからもランダムアクセスで螺旋ってのは無いわな >>349
ばっかおめえQDつったらMZ-1500だべ(老害発言 MZ-1500買ったのは倉沢淳美のファンが多かったんだろうな >>350
そうだったorz
700/1200/1500の関係がときどきわからなくなる
モノクロ/カラー/QDでよかったっけ？ 夢が広がるディスクシステム～♪
>>352
80K2E/1200/700./1500の順な なんか wiki にはSMR領域のデータ更新にはまず対象のSMR領域のデータを
メディアキャッシュに書き出すみたいに書いてあるが
流石にキャッシュメモリの間違いだよな？ >>332
バンドサイズとは？
いやバンドってのが瓦の何層かを一括とするって意味だとすると
サイズも何も無いよなーって気がする
最低書き込み領域（サイズ）って意味だとやっぱりブロックと言ったほうが正しいのではないかと SMR処理ではトラック単位で束ねられるだろうし、
中心からの距離によって容量が変わるはず。
なのでトラックを数本束ねたSMR処理の単位をバンドっていうんじゃないかね。
AS002あたりのSMRの記事だとブロックになってるから、なんか理由があって変えたんじゃないかな。 >>358
処理単位というかwikipedia曰く
全トラックを単一的に瓦として重ねてしまうと一番下の瓦の更新処理の手間が
べらぼーに高くなって使い物にならないので
何層か毎に瓦を区切ったのがバンドらしいので
例えば瓦3層で区切ったSMRなら瓦3層毎にバンドとしたSMRとしか言いようがなく
サイズも何もないのではと >>345
1GBについては>>313に聞いてくれ 「層」をどう受け取っていいのかわからん。
トラックの事？ SMRはバンド単位で一気に書かないといけない
この前提はわかってるよね？
バンドのサイズを越えるデータはバンドサイズ単位でシーケンシャルの判定によってメディアキャシュを使わない書き込みが期待できる
バンドサイズ未満のデータはメディアキャッシュに一旦書かれる。
だからバンドサイズ未満のデータを扱えば扱うほどメディアキャッシュ容量を圧迫し
溢れる事による極端な速度低下までの余裕がなくなってくる。
だからサイズに言及してるんだと思うけれど。 内周と外周で密度が違うから、
1ブロックxxMBとか固定じゃないって事かな？ >>363
だからバンドのサイズってなんぞやと
3トラック毎にバンドするっていったら3トラック毎に重ねないトラックを設定する事により
1つのトラック更新を3トラック以内の書き換えで済ませるようにする事でしょ
バンドサイズとはどこのサイズを指す？ バンドの中の一部データの書き換えにもバンド全体の書き替え(厳密には追記のはず)が必要
3トラックで1バンドなら3トラックの容量がバンドのサイズ
SMRの処理をする上での最低処理単位
だからサイズが重要 >>367
おお、つまりSMRの最小書き込みサイズは書き込み先のトラックサイズに依存した可変長であると
それは説なのか確定事項なのか トラック容量が可変でバンドがトラック単位なら
必然的にそうなる
というだけの話だよ。
SMR関連で明確に公表された仕様情報が殆ど無い中では
比較的素直に導き出される推測だと思うけどね。 追記だと、バンド位置によるサイズ可変と相性悪いな。
同位置で書き換えの方がしっくりくる。 >>369
必然なのは重ねられた部分の更新には重なった部分の更新も必要ってところまでで
トラック単位で行う必然性はないかなと思う
別にトラック容量の半分単位でやっても良いし
トラック容量以上のバンド数の倍数サイズの巨大な固定容量を
キャッシュメモリに積んで更新するルールでも良いかと
もちろんトラック単位の可変長でやっても良いとは思うが実際はどうなってるんだろう >>368
製品によってはアルゴリズムを単純化するためにブロック容量を同一にして
外周側ほど「捨てセクタ」が多くなっていたりしてな
（微妙な位置ずれへの対策として1bitでも書き換えが生じたらブロック全体を全部書き直すものもあったり？）
それが思うほど容量が増えない要因の一つだったり
ノウハウが貯まるにつれてアルゴリズムが改良されて容量可変になっていくとかの可能性も
あくまで空想（妄想） >>372
ブロックが固定長であっても色々難しそうよね
どう区切るんだっつー
トラック容量依存の可変長の方が現実的か？ いや、HDDにシーケンシャルライトという概念がある以上
HDDは一本のテープ媒体のようなものと見なすこともできると考えれば
あまりHDDの構造は気にせずに大きめのサイズでブロックを区切ってしまっても問題ないかな そういや最近のSMRってシーケンシャルライトの時は
メディアキャッシュを使わないようになってるとかどっかで見た気がするんだが
あれって本当なの？
だとするとバンドのリードが発生する分逆に書き出しがかなり遅くなる気がするんだが
もしかしてリードしないで書いてるのかな？ 何にしてもバンドのサイズを気にする意味が有ったという事でいいのかな？
少なくとも検証をするうえで結果に影響があるくらいには意味があると。 >>377
それはわからん。SMRがそれを意識して動いてるならあるだろうし
意識してないならないんじゃね
そもそもCMRではトラックのサイズなんてあんまり意識して動いて無いから
トラックサイズは一般的では無いんでしょ
何故意識する必要が無いのかは隣接するトラックへのシーク時間が極小だからなわけで
だとするならSMRにおいてもトラック毎に区切って考える必要はあまりなく
他の事象を優先に考えて動いている可能性も大いにある
例えば書き込み先のトラックサイズに依存して更新サイズを可変させるのは
制御が困難になるから更新サイズは固定長にしようとかな バンドのサイズを超えるか超えないかで処理に違いが発生するという話であって
トラックのサイズはバンドのサイズを決める上での要素の一つ。バンドサイズが固定長ならトラックのサイズは無視されてるだろうし。 >>380
いやまて、バンドサイズはトラックサイズ×バンド数の事だと思ってたんだが違うのか？ バンドサイズを固定長にする為にあえてあまらせるという選択肢も無しじゃないなと。
バンド更新の際に同じ場所に書き換えるのならバンドサイズ可変でも良いけれど、
追記をしているのならバンド可変は手間が増えるんじゃないかと。
他にもガベージコレクションとか考えるとサイズ固定もメリットあるなと。
2016年の記事にガベージコレクションやらバンドは書き換えじゃなくて追記とか言う内容のモノもあるんだよね。
年代的にAS002のことを言ってるんだと思うけれど。 >>382
バンドサイズを最短のトラックサイズに合わせるって事？
流石にそれはないだろ。トラックって最長と最短で倍位は差があるんだろ 別に合わせんでもいいのでは
サイズ差はキャッシュがでかい方に合わせりゃいいじゃん >>383
仮にバンドサイズ20MBだとすれば
トラック1本10MBのエリアならトラック2本でバンドを構成、
トラック1本8MBのエリアならトラック3本でバンドを構成。3本で24MB分確保して4MB余った状態になる。
トラック1本5MBのエリアならトラック4本でバンドを構成。
という手段も取れるというだけの話だろう。
ガベージコレクション的な再配置を行うのならサイズ固定の方が手順が軽いだろうし。 とりあえず >>386 の日本語の奴にバンドを書き換える場合は
一度メディアキャッシュに書き出すって書いてあるな
コスト倍どころじゃ済まないはずだけどよく誤魔化せてるもんだな
あとシーケンシャルライトはサイズによってはメディアキャッシュ使わないのも書いてあった
どうやってるのかは書いて無かったけどまっさらなバンドだけをかき集めて書いていくのかな
見つからなかったらどうするんだろうな OS的にはメディアキャッシュが更新できた時点で処理完了 パーティション切る時にバンドをまたいでる場合って何か悪影響ある？ >>390
基本的にはそうなんだろうけど裏でメディアキャッシュからバンドに
書き出してる最中にメディアキャッシュにアクセスしたら
ランダムアクセスっぽくなったりしないんかなとか メディキャッシュからの書き戻し作業中にホストからデータがきたらホストのデータ優先。
書き戻し作業などはいつでも放棄できるような手順になってるはず。
ホストのデータを優先できなくなると極端な速度低下症状に繋がる >>394
ってバンド書き込みの中断処理入るならそれはそれで
ホストからのリードも遅くなる気がするが体感できる程は遅くならないのかね そもそもがドライブ独自に動いてる処理なんだから、常に中断に備えたフローになってる。
だから書き戻し作業も放棄すればいいだけ。
再開は作業完了の記録が無ければその作業を初めからやり直すだけ。 ん？
バンド単位の書き戻しが始まっていたら、その1バンド分は中断出来んだろ？
1バンド分を不揮発性の領域に一度書き込んでからなら出来なくはないが、
そうでないなら、瓦書きの途中でやめたら、もうそのバンドのデータは次回の読み込みでは信用できなくなる。 >>397
「元データは必ずキャッシュかCMR領域のどちらかにある」ってやつじゃね？
書きかけだったSMR領域は破棄で次の書き戻し機会に全部上書きとか http://www.idema.gr.jp/common/pdf/news/tenbo2019.pdf
去年は配布がなかったIDEMA JapanのストレージとHDDの業界展望2019のpdf出てたから貼っとく
SMRについてどうこうってことは無いけどまとめ的な感じでいいかなと >>398
中断前提ならそうするしかないよね？
遅くなるけど。 >>400
>>386 にもバンド更新時は対象のバンドは一度メディアキャッシュに書かれると書いてある >>401
たしかに！
386の言うとおり、コスト倍以上だよね。
データベースのファイルとか絶対に置きたくないな。 2.5インチが750GBになってるな。
IDEMAとしては1TBプラッタの存在は認識してないってことか。
それなりに信頼のおける団体の資料だし、1TBプラッタはSMRしか無いとみていいのかね。
ベンチなんかで既にいろいろとネタは上がってきてるから今更なんだけど、
ユーザーじゃない立場の発行した資料でこういうのを見るとトドメな感じがしてしまう。 >>402
そもそもメディアキャッシュの書き戻しはバックグラウンドで行われるものだから
キャッシュが溢れない限りは全く関係ない話だよ。
むしろランダムライト自体はCMRのみよりも高速になる。 >>403
750GBプラッタだと東芝のMQ03ABD300（750GB x4）がだいぶ前から出ている
それとは別にWDのWD40NPZZがCMRだと言われていて、もしそうなら800GB x5と言う事になりそうだ >>405
いや、昭和電工発表の1TBプラッタがSMRで確定かねというはなし >>404
バックグラウンドだからまったく関係無いっつーのは安直じゃね？
というか普通バックグラウンドだから大丈夫っていうのは
バックで別の人が別のリソース使用して作業してるから言えるのであって
この場合バックもフロントも同じディスクやヘッドだからな バックからフロントへのリソース切り替えで躓いたらそのまま
フロントの処理遅延に直結するじゃんかと 正に店員が一人のコンビニと同じ状態だな
品出しはバックグラウンドだからノンビリやっても客には影響無いかってそんなわけはなく
バックグラウンドからレジに出るのに遅れたらその分客は普通に待たされるっていう メディアキャッシュの操作はドライブファームの管理下にあるんだし、
ホストからアクセスがある間は書き戻しを行わなければ済む話では？
ドライブファームによる独自の動作をしてる状態に
ホストの指示が有った場合の復帰のペナルティに関しては
内部を解析でもせん限りはりわからんでしょう。
ホストからの指示に従う部分とSMR動作を行う部分のリソース共有度合次第だろうし。
でも仮にペナルティが有るんだとしても、
シーク動作とかのタイムスケールに比べたら微々たる問題じゃないかね。 ホストからのアクセスが続くとメディアキャッシュがあふれて動作遅延が出るってのは
シーゲイトのSMRの症状そのものでしょ。
これはつまりホストからの動作が優先されてることの証明だと思うけれど。
ホストからの指示を押しのけてまでキャッシュ書き戻しを行うのであれば
この症状は出てないと思うし。 >>407
何視点で語ってんのか統一しないと意味ない
OSかファームか ヘッドが三個ぐらいあって、役割を分担出来れば良くなりそう。 受け取りデータのSMRバンドへのフラッシュはWDなダイナミックマッピング方式と
海門なスタティック方式とではちょっとやり方が違うみたいね。ただし両社に共通している点はある。
瞬間停電なような電源断が発生しても上書き前のデータをきちんと保持できるような
安全面が考慮して常時HDD上のどこかに書き換え前のバンドを保存してあること。
WD的には上書きせずに追記。海門的にはスクラッチ保存後に上書きという二度書き。
ま、現用機の実装が上記の通りであるかはしるよしもないけれどw
----------
The cost of cleaning a band may vary based on the type of the block mapping used. lWith dynamic mapping an STL can read a band, update it in memory, write the updated
band to a different band, and fix the mapping, resulting in a read and a write of a band.
With static mapping, however, an STL needs to persist the updated band to a scratch
space first―directly overwriting the band can corrupt it in case of a power failure―
resulting in a read and two writes of a band. 安全面が考慮して >> 安全面を考慮し
以下オマケ
-------
shows the logical view of Seagate ST8000AS0002 DM-SMR disk that was recently
studied in detail. With an average band size of 30 MiB, the disk has over 260,000 bands
with sectors statically mapped to the bands,
and a -25 GiB persistent cache that is not visible to the host. The STL in this disk
detects sequential writes and starts streaming them directly to the bands,
bypassing the persistent cache. Random writes, however, end up in the persistent cache,
dirtying bands. Cleaning a single band typically takes 1-2 seconds, but can take up to 45
seconds in extreme cases. >>414
ダイナミックマッピング方式は上書きせずに追記。ということで >>229 のサルベージ屋さんの
ガベコレ話を思い出すのだが、ガベコレが実バンドアドレスと論理バンドアドレスの不整合の
解消を目的として本来あるべきバンドに追記分を書き戻す。ということならアリかもしれない。
これに対してスタティックマッピングではバンドは常に実バンドアドレスであるからそんな
囲い戻しは不要。かもね。
ダイナミックマッピング方式だと書き換えが生じると別バンドへ追記書きが生じるから
ファイルの連続性は機械的に失われる。そもそもDBのようなランダムファイルでしか
そんな追記は起こらないから、まあいいか。というニュアンスなのかもね。
このダイナミックマッピングだとマップテーブルが壊れた場合のサルベージはスタティック
方式より難しくなりそうね。俺的にはHDDが壊れた場合のサルベージ難度を考慮すると、
サルベージ用のソフトもイロイロ手元にあるので。こっちかな。みたいな。 >>413
それだ！
ディスクは回っているだけだから、
メディアキャッシュから本来の位置へ書き戻す専用ヘッドがあれば、かなり耐えられる。
振動ヤバそうだけど(笑) そこまでコスト掛けるならメディアキャッシュやめてNANDでかいの積んだほうがよさそうだけどね。
MACH.2の2分割駆動をうまく生かす方向なら何とかなるかもしれんけど、
2分割なら動作を連携させるよりも完全分離の方がよさそうだし。
SATAコマンドを2系統同時に処理するみたいな話のようだし Seagateの同時投入された14TB HDDに使われてる新型1.75TBプラッターはCMRと言われてたのに、
https://www.facebook.com/seagatemy/photos/announcing-the-14-tb-exos-x14-cmr-enterprise-hard-drive-offering-maximum-density/2273902799349121/
> Announcing the 14 TB Exos X14 CMR Enterprise hard drive, offering maximum density, scalability, power efficiency and security.
https://www.kitguru.net/components/hard-drives/simon-crisp/seagate-exos-x14-14tb-hdd-review/
> Recording Method: conventional magnetic recording (CMR)
同じスペックのプラッターのX14 14TB ST14000NM0428がHost Managed SMRと書かれてる
1.75TBプラッターが全てSMRなのか誤記なのかHM SMR互換のCMRなのか、よく分からない
Seagate Exos X14 14TB 512E SATA HM SMR Product Manual
EXOS X14 14TB ST14000NM0428 / ST14000NM0448
ZAC Host Managed zoned device.
https://www.seagate.com/jp/ja/support/internal-hard-drives/enterprise-hard-drives/exos-X/
https://www.seagate.com/files/www-content/product-content/enterprise-hdd-fam/exos-x-14/en-us/docs/100829477b.pdf
1.75TBプラッター 14TB
BarraCuda Pro 14TB ST14000DM001
IronWolf 14TB ST14000VN0008
IronWolf Pro 14TB ST14000NE0008
SkyHawk 14TB ST14000VX0008
EXOS X14 14TB ST14000NM0018 / ST14000NM0258
EXOS X14 14TB ST14000NM0428 / ST14000NM0448
Heads 16
Discs 8
Recording density, KBPI (Kb/in max) 2426
Track density, KTPI (ktracks/in avg.) 436 (トラック密度がSMR 2TBプラッターより明らかに低い)
Areal density, (Gb/in2 avg) 1058
SMR 2TBプラッター
BarraCuda 4TB ST4000DM004
Recording density (max) 2294 kB/in
Track density (avg) 540 ktracks/in
Areal density (avg) 1203 Gb/in^2 ひょっとして6年前の2TBより今の2TBって性能が下がるのか？ 文書のタイトルでHMSMR明記してるんだしSMRじゃないってことは無いと考えると
データシートをコピペして修正忘れというオチじゃないかな？
仮に同じ磁気記録密度のプラッタをベースにしてSMRを採用したとしても、
SMRバンド間のガードバンドの存在やセクターギャップのことを考えると
CMRでの記録スペックと同じになるわけないと思うし。
それをわざわざ同じにするメリットもない。 新しい技術の一般化、はよ
SMSR課なんかそんな感じの奴 >>414
そらそうだろ。そんな理由での破損させたら大問題というか笑い者にされる。キャッシュクリア時の処理なんて昔から色々試行錯誤されていて枯れた技術も沢山あるし
問題は書き込み直後のハッシュチェックが何の意味も無い事かな。まぁ元々念の為のモノだけど同レベルを求めるとメディアキャッシュクリアしてからになるし、そもそも同一バンド(？)の書き替えで書き替え発生するからSMRで気にしたら負けかなww 3.5インチは東芝だけCMRで、他社はみんなSMRに移行した、でOKなのかな？
複数チューナーによる同時録画などはまだCMRじゃないと駄目だけど、
一般人の通常用途ならパワーアップしたSMRでアーカイブ以外の使用も可能になった。
これであってる？ WDもシーゲイトもDMSMRは最安ラインのみ
東芝もSMRを出す準備は進めてる
「一般人の通常用途」の定義が不明
使用に問題が出るかどうかの判定境目はドライブファームにランダムライト判定される書き込みが
メディアキャッシュ容量以上に連続するかどうか。
WDとシーゲイトではDMSMRの制御方式が違うので同一視はしないほうが良い 2.5インチのSMR化が進んでるのは確かだけど
3.5インチはまだまだじゃない？ 大容量化のために5インチHDDの復活を容認する消費者は過半数だと思うけど、
それをしないのは技術的に難しいのかな >>435
いっそのこと 8インチドライブはいかが？ って大昔ぷらっとほーむ開業直後本多のオヤジに
日立の8インチを押し売りされたことあったなあ。SMDインタフェースのやつ。
8インチHDDが先端技術だった頃はウィンチェスター型ハードディスクとか呼ばれていた。
海門の前身はIBMの外部記憶開発エンジニアだったアラン・シュガートがスピンオフして
立ち上げたシュガート ・アソシエイツ。8インチのみならず5インチFDDのデファクト。
そのシュガート が次に立ち上げたシーゲートの大ヒットがST-506。5MBの5インチフルハイトHDD
PC/XTの標準内蔵HDD。これも初期PCのデファクト。
外観的にあの時代に戻るノスタルジーを感じるのはやっぱり爺だけだろうね。終活乙。 >>426
CMRなHDDって伝統的にターゲットセクタに直な上書きしかしないでしょ。
スクラッチセクタに別書き一時保存とかはしない。だから瞬間停電とかの事故対策が重要で
Unix系ではトランザクションとかジャーナリングとかHDDの外側で対策が図られてきた。歴史。
瞬停電対策という点でSMRはスクラッチ保存という護送船団的な保護機能の点でCMRより
安全性が高いと言えるかもしれないね。SMR逝くときは去くだろうけど。気持ち少しだけ。 5インチや8 インチって今どきの記録密度で外周まともに読めるのか？
おまけにモーターが大変なことになりそう >>437
ようわからんがそのCMRのターゲットセクタの書き込みってのが
SMRのメディアキャッシュの書き込みにあたるだけじゃないのか？ シーゲイトがSMRのメリットとしてメディアキャッシュに一旦書ききることの安全性をPRしてるんだし
それなりの意味はあるんじゃない？
ターゲットセクタへのちまちまとしたランダムライトよりも
メディアキャッシュに一気に書ききるほうが
データもらってから不揮発媒体への記録完了が速いのは確かなんだし。
ただしそれはSMRのメリットじゃなくてメディアキャッシュのメリットだけど。 なるほど、物は言いようか
いや、ランダムライトな物はメディアキャッシュ内でもランダムライトだとは思うが
外周で範囲が限定される分マシではあるか
メディアキャッシュの溢れが発生したらそれどころでは無いと思うが
まあ、発生しない前提なんだろうね メディアキャッシュではシーケンシャルで書いてるでしょ？
実際にベンチではランダムライトが異常に早い結果が出る場合も有るし。 >>439
マルチアクチュエーターとバッファNAND
つければ実用のスピード出そうだが。
CMR3,5インチで16TB
MAMR HAMRで18TB 20TBが来年でる今
本当にいるのか？
金型作るのも強トルクモーターも金がいる
Googleが資金だして共同開発するなら
目処ありそうだが 5インチ作るくらいなら厚さ2倍のドライブ作ったほうが良いんじゃないか？
スピンナップにさえ気をつければ特に技術革新不要な気がするし サーバー的には容積辺りの発熱と容量が大切なんだよな。
だからSSDがシェア増えてきてる。
なんせ土地代に比べればユニットコストなんて安いでしょ。 >>446
土地代、電気代、空冷代
故障時の交換要員
全部コストだもんな だからといって数百TBクラスのストレージ構成するのにSSDは現実的じゃないでしょう。
SMRにしろそれ以降にしろ、HDDがねらえるのはもうそこしか無いだけど >>448
どのような手段が安くつくかは、思い込みで考えずに一つ一つ数えていかないとわからないよ。
機械だけが安くついても、維持費がかかってしまう場合もある。
モノは持つだけで維持費がかかるから。特に都会なら場所代 >>443
そんなわけなくね
少なくともファイル1個書くのに内容以外にHDD内のファイルとアドレス管理してる部分も
書き換え無ければならないはずだからファイル毎にシーケンシャルは途切れるはずでしょ
異常に早いのは揮発のキャッシュメモリ使われた場合じゃね？ >>449
数百万はする100TBクラスのSSDって売れてるのかね？
発売されたーみたいなニュースは目にするけれど
採用されたって話はあまり聞かない。
その筋の業界では立派に存在感を示しているんだろうか？ >>450
ファイル毎にシーケンシャルが途切れるからhddに対してランダムライト的な要求が発行される。
hdd側はそれをメディアキャッシュにシーケンシャルで書き込んでいく。
だから、一定量までのランダムライトがちょっと低性能なssdくらいの性能に見える。 >>453
よくわからんがファイル書き込み毎にHDD内のアドレス情報を書き換えずに後回しにするなら安全性が死ぬだろ
アドレス情報書き換えを後回しにした間に瞬電起きたら複数ファイルが死ぬからな
ファイル毎に書き換えるなら当然シーケンシャルな書き込みにはならない
ファイルとは関係無い場所を書き換える事になるだろうから >>454
すまん、話がかみ合ってないな？
osがhddに対してlbaアドレスのn番地からxxxデータを書き込んでくれとコマンドが来るだろ？
hddはメディアキャッシュにそのアドレスとセクタデータをシーケンシャルに書き込む。
暇な時にメディアキャッシュから本来のアドレスに書き直す。
細かい動作に異論はあるだろうけど、だいたいこんな感じじゃないの？
ランダムライトでもメディアキャッシュに余裕がある間はシーケンシャルになるという話だよ。 >>454
補足すると、メディアキャッシュはosから見えるlbaアドレスとは切り離された領域にあるんだと思うよ。 >>455
その方式だとメディアキャッシュにあるデータをosから読めなくね？ >>458
メディアキャッシュにあるデータが本来の場所に書き直されてクリアされるまでは、本来の場所の読み込みはメディアキャッシュから読まれる仕組みとしか考えられない。
また、メディアキャッシュも管理している領域があるだろうから、細かく言えば完全なシーケンシャルアクセスにはならないから、
その事を言ってるのかな？とも思った。
他の人がシーケンシャルと言ってるのも、その点もわかった上でほぼシーケンシャルと言っているのかと。 メディアキャッシュのセクタ代替データをどこに記録してるかって話かな？
ランダムアクセスのそれぞれの代替情報をディスク上に記録してるのなら
それをいちいち書き換えに行くからシーケンシャルにならないと。
ディスク上に記録してたらすべてのアクセスでセクター代替テーブルを参照してからデータを読みに行くことになるし、
突然の中断に対応するという意味でもディスク上ではないように自分は思うけれど。
もしくはセクター情報までまとめてシーケンシャルで書き込んでからDRAM内に参照用に変換テーブルを展開するとかでもいけるか。 >>460
俺もちょっと思ったけど、そこまて厳密な話は出来ないかな。
全て断片的な情報からの予想に過ぎないから。 SMR関連は殆ど情報出てないしね。
今後のTDMRに繋がる技術でもあるし、
実績を積み重ねてアルゴリズムを進化させてる段階だろうしで
SMRってだけの情報じゃかえって混乱する場合もありそうだしね。
SSDのコントローラは論理アドレスとの変換テーブルはどこに持ってるんだろうか？ >>456
OSからはLBAでしか触れない
つまりキャッシュにデータが乗ってる間はLBAと不分離
でないとキャッシュにならないよ >>463
大丈夫、
もちろん、そのつもりで書いてる。 >>459
だからlbaだろうがなんだろうが書き込んだファイルがメディアキャッシュ上の
とあるアドレスにあるって事をファイル書き込み毎にHDDに書かないとosからアクセス出来なくなるでしょ
それを書くって事はシーケンシャルライトにはならんわけで
それを書かないとメディアキャッシュ上のファイルにosからアクセス出来ないから
HDDにファイルを書き込んだ瞬間osから見えなくなるという怪奇現象が発生するぞ >>464
つまり、切り離された領域（物理）って事？
そんで、>>454 は間違ってるんだから補足してどうすんの？
まず454の誤解を訂正しなきゃ シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
シーケンシャルライトの途中で瞬電してもその単体ファイルが死ぬだけで
これはSMR限らず同じことで
普通のならNTFSのファイルテーブルを更新して
SMRのメディアキャッシュに書くならメディアキャッシュ含めたファイルテーブル的なものを更新
だからSMRであってもなくても連続したエリアに書き込む場合であっても
複数のファイルであればシーケンシャルライトにならないってことでしょ？
リードの場合はファイルテーブルを更新しなくていいからシーケンシャルになる >>465
だから、そう書いてるでしょ。
>>466
メディアキャッシュに限らずキャッシュてそういうもんだよ。
通常のアドレス空間から切り離された領域にあってキャッシュしている時だけそのアドレスの代替としてアクセスされる。
一定のアドレスを持っているわけではない。
それくらいは前提として共通認識と思って話してたんだけど、、、 メディアキャッシュの内部の管理方法は外からじゃ判断付かないし答えなんて出ないんでは？
この話発端としていえば、
メディアキャッシュ機能自体がランダムライトの改善効果があるとHGSTは公言していること。
2倍とか3倍のスケールで改善しているってことなんだし、
例え管理領域へのアクセスがあるのだとしても結果として改善効果がということ。
コレがもしDRAMキャッシュ由来の効果なのだとしたら、
同レベルのDRAMキャッシュサイズ持ちのドライブでも同等の改善効果があるはず。 ファイルテーブルも異ファイルもメディアキャッシュに乗せてシーケンシャルすんだよ
吐き出しはあとあと >>469
全くその通りで、思いつく常識的な範囲での想像でしかない。 ありゃ、Wi-Fi切れてスマホのキャリアから書いてた
>>468
何周遅れしてんのよ
ファームウェアすらメディアに載せてんのに
ファイルテーブルも異ファイルもメディアキャッシュに乗せてシーケンシャルすんだよ
吐き出しはあとあと >>469
ランダムライトであってもメディアキャッシュ部は外周部分を使うので
メディアキャッシュに書き込むファイルテーブル部と実データを書き込むメディアキャッシュ部が近いので、
またそもそも外周部のほうが書き込みスピードが速いので速い
よってアイドル時にメディアキャッシュから再記録することを除外すれば速いのは確か
>>470
位置を書き込むファイルテーブルをランダムに書いてたらそのファイルテーブル読めないじゃん
なにいってんのさ ファイルテーブルも実データも、ファイルシステムとしてOSが管理区別している
ファームウェア側からはうかがい知れないよ アンカーつけないと気が付かないかも
>>473
>>474 を読んでね そういや、ファーム側から見てるのかOS側からなのか、区別つけないで論じてる人が前にもいたな >>474
フォーマットのファイルテーブルとSMRのファイルテーブルは当然別 >>478
何から見てじゃないでしょ
人間が外から見てだよ すまん SMRのファイルテーブルというよりメディアキャッシュを管理するためのファイルテーブルだな >>479
概念レベルの話をしてんじゃないよ
SMRのファイルテーブルって何？ リロードすりゃ良かった
>>480
メディアキャッシュとLBAの対応表だろ
なおさらユーザーやOSからは通常知り得ない話だよ >>483
知りえない情報であってもそれはフォーマットのファイルテーブルと同様に
ファイルを書き込みを閉じた段階で書き込む必要がある、書き込み位置が決まっているのは当然の話 通常＝専用のデバイスドライバ入れない状態
でさ、ファームウェア側からは書き込み要求されたLBAしか知り得ない
対応の辻褄を合わせてキャッシュ吐き出すまでキープ
>>484
> 決まっているのは当然の話
決まってないよ
決まるとする根拠はファイルシステムのテーブル（メタデータ）だからでしょ
でもそれはファームから見るとメタとファイルの中身の区別はつけられないよ
あるのはLBAの違いだけ
ファーム側から見ると、ファイル単位で処理を切り替える理由って、OS側で通常のディスクキャッシュクリアの要求をしてベリファイかけるときくらいじゃないの？ 曖昧な「テーブル」という言葉を使ったせいで、
・fsレベルの書き込み
と
・ファームウェアレベルの書き込み
を混同してるね
メディアキャッシュやメディアキャッシュとLBAの対応はファームウェアからしか見えないし、fsの実データとメタデータの区別はOSからしか見えないよ >>485
決まってなけりゃメディアキャッシュ管理はできませんよ
どこにどこ用のデータが書いてあるかわかんないんだから
>ファーム側から見ると、ファイル単位で処理を切り替える理由って、OS側で通常のディスクキャッシュクリアの要求をしてベリファイかけるときくらいじゃないの？
CMR HDDであってもファイルの書き込み終了ごとにファイルテーブルを書き込まないとファイルテーブル書くまでの物は
瞬電などがあれば全部飛ぶ >>486
混同してるのはあなたでしょ
CMRの場合はフォーマットのファイルテーブルしかないし
SMRの場合は別にメディアキャッシュのファイルテーブルが存在する
SMRHDDがみる分にはntfsのファイルテーブルはデータでしかないしどこに置こうがメディアキャッシュのファイルテーブルがあればどうでもいいが
メディアキャッシュのファイルテーブルは位置が決まっていないとそれをもとに再書き込みや指示を実行できない 追記：
実用上は長い連続書き込み要求が来たら、直接要求されたLBAに「真のシーケンシャル書き込み※」が挟まり、短いようだとキャッシュ経由に戻る
ここはファームのチューニングの腕の見せ所
※連続したLBA書き込みが連続した磁性体への書き込みとなるかどうかはファーム内のさらに下のレベルで隠蔽されている
>>487
飛ばないよ
メディアキャッシュに残ってる >>488
一つ前の型の茂で既にCMRにもメディアキャッシュ積んでるよ
そもそもどうやってファームがfsを知り得るの？魔法？ >>489
メディアキャッシュに残っていてもどっからどこがどのデータかのデータがなければ
復元できない >>490
知る必要はない
SMRHDDがみる分にはntfsのファイルテーブルはデータでしかないしどこに置こうがメディアキャッシュのファイルテーブルがあればどうでもいい >>491
メディアキャッシュに関するメタデータはファームウェアが実データの先に書き出し後に消すだけだよ
これで飛ぶなら飛ぶタイミングを例示してくださいよ
>>492
「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
なんですり替えるの？ >>493
メディアキャッシュのある部分に書いてあるものは本来LBAXXXXXXからXXXXXXXに書くものというデータ（テーブル）が必要になる為
そのテーブルを書き込む前にデータだけ書き込んで止まったら飛ぶ
>「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
こっちもそれを否定していないしすり替えてもない >>494
データだけならファームは書き込み完了と判断しないよ
メタデータに齟齬がないかチェックするルーチンが入ってる
齟齬があったらメディアキャッシュの方を採用し、完了してない方は廃棄する
つまり飛ばない >>494
>> 「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
> こっちもそれを否定していないしすり替えてもない
すり替えたよ
ファイル単位で閉じたらメディアキャッシュもいじるって主張してた↓じゃん
>>466
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが >>495
だから複数のファイルを書き込むときに毎回テーブルを更新しないと
最後にテーブルをまとめて書こうとすると前回のテーブル更新以降の書き込み全て齟齬があることになって飛ぶじゃない アンカー間違えた
>>494
>> 「ファームからしたらfsの都合は関係ない」はこちらが最初からしている主張だよ
> こっちもそれを否定していないしすり替えてもない
すり替えたよ
ファイル単位で閉じたらメディアキャッシュもいじるって主張してた↓じゃん
>>467
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
ディスクに書くがって↑これはなに？
fsレベルなら混同してるし
ファームレベルならすり替えてる
>>497
また混ぜる
fs？ファーム？ >>496
ファイルと書いたが
実際にはOS側が書き込み順を指定した場合ね >>497
これfsのテーブルだよね？
でも494のはファームウェアレベルだよ
混同してるね いい加減区別してくんないかなあ
>>499
これの説明をしてください
> シーケンシャルライトが終わったりファイルを閉じたりするとファイルテーブル的なものをディスクに書くが
「ファイルテーブル的なもの」って何？ メディアキャッシュだけに書き込まれたデータはOSからは読み出せないわけで
それはない物と同じこと メディアキャッシュのキャッシュヒット判定のセクタ代替情報がどこにあるかって話でしょう？
どこに有るかは知らないけれど少なくともディスク上に有ったら遅すぎて使い物にならんと思う。
いちいちヘッドシークしてメディアキャッシュ領域のセクタ代替情報を読みにいくとか非効率すぎ。
普通に考えたら専用メモリ、コスト考慮してDRAM内じゃないかと思うんだけどね。
なのでディスクに記録されるセクタ代替情報は参照されることが前提の配置である必要は薄く、
メモリ展開されるセクタ代替情報が構築できる程度に纏まってれば良いとする事ができる。
例えば各トラックの先頭セクタにそのトラックの各セクタの代替情報を纏める程度とか。
もちろんこれは勝手な推測 >>504
キャッシュはキャッシュなのでDRAMにあれば毎回読みに行く必要はないので非効率は関係ない
DRAMは電源落ちたらそれまでなので問題は解決しない >>502
・fsのテーブルとメディアキャッシュの対応テーブルを混同しないこと
・CMRにもメディアキャッシュ採用機種がある
せめてこの2つを頭に入れてから論じてください >>505
マジックなりCRCなりを併用すれば、不意に落ちても問題ない 上記はパーティションテーブルやRAIDのアレイ情報などで使われている枯れた技術 >>506
混同しているのはあなた
SMRの場合はキャッシュを使っている以上対応テーブルが必要になる
CMRでもメディアキャッシュを採用しているならSMRと同様の動きになる
>>507
落ちたらインデックス最新更新以降のデータは落ちるから問題大有り >>505
メディアキャシュのキャッシュヒット判定ってのはメディアキャシュ内にセクター代替されているかどうかの判定ってことね。
盛んに議論されているセクター代替情報の参照の事。
これがディスク上にあるのだとしたら非効率と言っている。 >>509
また変なこと言い出す
対応テーブルをどうしたいの？
>>509
ログとCRCとセットにしておけば、エラー箇所が割り出せる
あとはエラーのない操作をしたところまでキャッシュを廃棄しログを巻き戻せばいいだけ
fsのジャーナリングと同じ そもそもこの話題にはOSもファイルシステムも関係ない話だよね？
ホストからのセクタ指定とそのデータの指示において、
ドライブファームがどうやってメディアキャッシュを制御しているかという話であって。
ホストからはメディアキャッシュは見えないし、ドライブが勝手に代替処理をしている。
制御の手法としてはただのキャッシュ機構。
メディアキャッシュという特性を考慮してどう効率化するのかという話なだけ。 >>510
ディスクにあってそのキャッシュをDRAMに持ってそっちを使ってるから非効率ではない >>511
ログ書くならインデックス書くのと一緒だろｗｗ >>514
つうかfsのジャーナリングでピンとこないようでは話にならない たびたびログ書いてるならシーケンシャルライトになってない >>517
たびたびじゃないよ
マジックとかCRCはデータ自体とは比較にならないほど「小さい」 ジャーナルと同じことやってんならシーケンシャルライトじゃない
小さい小さくないの話は最初から出てなかった
たびたびじゃなければ最新の更新前は飛ぶね >>520
キャッシュと本来格納されるLBAとに瞬電などで不整合があっても簡単に廃棄できるの
>>487あたりから長々と見当違いの考察垂れ流しやがって >>520
同じことじゃないよ
メモリ持ってないとでも思ってたのか
例えば茂で騒動になったのはログ用のリングバッファメモリ より具体的な例を書くと
「a.txtとb.txtをメディアキャッシュ上の連続領域に書くときそれはシーケンシャルライトになるか」
といった話だよな
俺はならないと思うけど >>521
廃棄できても最新の更新前は飛ぶし問題ないことはない >>524
え？ログ用のはDRAMじゃないよ？
少量だからリングバッファで使いまわすんだし >>526
重要なのは揮発か不揮発では？
不揮発領域への書き込みならそこまでヘッドを移動しなくてはならんよね >>523
そのテキストファイルがそれぞれ1セクタを使うとして考えると、
「その後の使い方次第でシーケンシャルに書くこともできる」
だと思う。
要はメディアキャッシュ内の管理情報をデータと並べて書くかどうかという話でしょ？
通常の領域へのアクセスにおいても代替情報を参照しなければいけない以上は、
代替情報はディスク上にあるだけでは遅すぎてダメ。
より高速な媒体で実運用する必要がある。
つまりディスク上の代替情報自体は常時参照されるわけではない。
ならば手間をかけてデータと別に記録する必要はない。
とすることもできるでしょう。
内部解析でしないと答えは出てこないだろうし、きっとメーカーでも違う。 https://www.amazon.co.jp/gp/customer-reviews/R34F3SJL4S7KZS/ref=cm_cr_getr_d_rvw_ttl?ie=UTF8&;ASIN=B07911QK3X
5つ星のうち4.08TB*4 RAID6 で使用
2019年1月4日
容量: G : 8TBスタイル名: PC向け 3.5インチAmazonで購入
HGST の 4T がSMARTをはいたので ディスク交換か・・新たに作成か・・
10TBは割高で8TBを探したが・・あまりいい評価の製品は無かったので
最も安価なBarraCuda 8TBを4台購入
万が一に備えてRAID6で組むことに・・
もう一つ上のIronWolfを3台 RAID5 より安価に済みました
RAID6作成に 16時間以上
NFSで約 9TB のコピーに 82時間以上
比較には 25時間以上
raidチェックに 18時間以上かかりました
;(；ﾞﾟ'ωﾟ'); いいこと考えた
メディアキャッシュをメモリチップにしよう >>528
その場合メディアキャッシュにあるa.txtのデータをosがほしいと言った場合どうなるんだ？ DVD-Rのパケットライトみたいな意味でのシーケンシャルライトとか？
あるいはジャーナリングみたいな
ドライブが全て内部でLBA差し替えしちゃうからドライブ外からは分からない なんであれ隣接トラック以外のシークが発生しない書き込みが
シーケンシャルライトだと思うが >>531
メモリに展開されたセクタ代替情報をもとに
ドライブファームがメディアキャッシュ内の代替先から読んで返す >>534
そのメモリは揮発領域の事だよね？
そのセクタ代替情報はいつ不揮発領域に書かれるの？ メディアキャッシュに書きこむんだからその時に書いてる。
その書き込み場所がどこかという話でしょ？
メディアキャッシュ内の管理領域でもいいとは思うけれど、
ディスク上に記録されるまでの時間が最も危険な時間と考えると
そのトラックに一緒に書いても良いじゃんと。
纏めて管理領域に書きたいのは参照時に効率がいいからじゃないの？ メディアキャッシュなんてドライブファームからしかアクセスできないんだし、
内部でどんな管理してるかなんて勝手に想像するしかない。
管理領域に書いているという論を否定することは自分にはできないが、
書いているはずだという決めつけもまた同じ。
だから管理領域じゃない可能性もあると言っているだけ。
ランダムライト改善効果があるというメーカー主張がある。
それ以上でもそれ以下でもない。 >>536
そのトラックに一緒に書くというのは a.txt のデータと同じトラック内に
a.txt はここにあるという情報を書くということ？
そうなるとその a.txt がここにあるという情報はメディアキャッシュを総洗いしないと読めなくならない？ ドライブ起動したときに読めばいいんじゃない？
さすがに全読み込みだと起動に時間かかっちゃうだろうから、
トラック内でのまとめ位は有ったほうが良いと思うけれど。
後はメディアキャッシュ更新のたびに同時にメモリ上の参照情報も更新できる。
実際の数値まで考えてないけれど、流れとしては出来そうかなと。 >>539
トラック内でのまとめって何？
不揮発領域に書かれる何かのようだけど イメージとしては「管理領域」が各トラックごとに有ると思ってもらえれば。
トラック1周すれば書き込み完了するような。 >>541
そのトラック内でのまとめも例えば a.txt の書き込みについては
a.txt の書き込み完了時に書かれてる保証は無いわけだよね
つまり a.txt 書き込み後のトラック内でのまとめに書き込まれるまでの間に HDD の電源が落ちると
トラック内でのまとめから a.txt はロストすると思うんだけどその場合はどうなるの？
HDD起動後 a.txt は無かった事になる？ キャッシュの書き込みパケットごとにキャッシュされたデータが順次消えるとでも思ってるんだろうか
ふつうブロック単位で書き込み終わったら消えるだろ。何のためのキャッシュだ こういうのは「自分で作るとしたらどんな実装にするだろうか？」って妄想しながら考えると面白いし、理解も進む。 >>542
そのリスクはどこに管理領域があっても同じでしょ？
ホストからデータをもらって一番最初にディスク上に記録されるまではみな同じリスクだと思うけれど。
ディスク上の本来の場所への書き込みだったとしても、
シークしてあっちこっちに書いてる時間よりもメディアキャッシュに一気に書いたほうが結果的に早く、
データが喪失してしまう危険な時間が短いという状態になる。
いったい何の話をしてるのかわからなくなってきた
もともとは
・メディアキャッシュへの書き込みはディスク本来のエリアに対するランダムライトよりも早い。メーカー談。
・シーケンシャルになるから？
という話だったと思うんだけど。 >>542
回答としてちょっと訂正。
一周したら書き込み終わってればいいと思うよ。
a.txtの書き込みとb.txt書き込み、それらの代替セクタ情報、トラック1周している間に全部書けばいい。
書き換えだと喪失リスクがあるから2か所のトグル式でもいいと思うし。
その一周してる間の電源喪失リスクの話かと思って>>545を書いた。 >>542
もはやSMR/CMR、キャッシュ有り/無し
全然関係ない話になってない？ 書き換え数に制限の無い次世代不揮発性メモリがメディアキャッシュの役を負うと思ってたけど、
開発が間に合わなかったようだ >>545
管理情報の場所では無く更新タイミングが問題だと言っているんだよ
a.txt の管理情報の更新まで含めて a.txt の書き込み完了としないと
どこかで信頼度の低下を招く綻びが生じると私は思っている >>541
CM大の論文ではDMSMRのメディアキャッシュに某バンドセクタの更新情報が書き込まれると、
当該のバンドに関してダーティフラグを立てて要更新ステータス状態に旗上げするらしい。とか。
STLはトランザクション管理メカニズムの一種だろうね。
Consequently, when a write operation updates some part of a band, the STL writes
the update to the persistent cache, and the band becomes dirty.
An STL cleans a dirty band in the background or during idle times, by merging updates
for the band from the persistent cache with unmodified data from the band,
and writing back to the band, freeing space used by the updates in the persistent cache.
STLはSSDのFTLに相当するキャッシュ制御メカニズムのことね。
DM-SMR disks, on the other hand, implement a Shingle Translation Layer (STL)―similar to
the Flash Translation Layer (FTL) in SSDs―that manages data in firmware while exposing
the block interface to the host. >>546
トラック一周って外周だと3MB位になるけど
最低書き込みバイトが場合によっては 3MB 位になるって事？
100KB のファイル書くのにも3MB書く事になるけどそれだと全然早くならなくない？ >>549
HDDの内部動作を考える場合、一連のファイル操作は捨象して考えた方がいいような希ガスる >>546
よくわからないんだけど、メディアキャッシュ内のCMRって一周丸ごと書かないといけないの？ >>554
そんなわけは無いけど >>546 を実現するにあたって a.txt を書いたあと
トラック内のまとめを更新するまえに他のトラックにシークされていいの？
一周丸ごと書かないにしろ一周丸ごと回るまで他のトラックへのシークは防がないといけないんじゃないの？ >>550
SMRバンド側にフラグたててメディアキャッシュ見に行けって流れってことかな？
変換テーブルだのをはじめから作って処理するよりは実装楽そうだけど、
メディアキャッシュに収まったセクタへのアクセスはいったん該当SMRバンドまで見に行くってことか。
通電中の2回目以降のアクセスはメモリ上に代替アドレスマップが次第に構築されていくって感じかね。
そういう意味では代替情報はメディアキャッシュ内の管理領域というよりも、
該当SMRバンドまで無効フラグを建てに行くって感じか。
メディアキャッシュ内に全部収めることばかり頭に有ったわ。 >>555
さらによくわからないんだけど、
ヘッドアクチュエーターのシーク制御ってドライブファームがやってるんじゃないの？
勝手に何かほかの制御が割り込んで動かしちゃうものなの？ >>525
更新前は残る
DRAMじゃないんだし
>>547
そうだよね >>546
ユースケースで考えるとその方式にはもっと致命的な問題があったわ
外付けHDDとしてa.txtとb.txtを連続で保存して閉じるで書き込もうとして
b.txt書き込み中にHDDの電源を落ちたとする
CMRだと当然a.txtは管理情報まで書き込み完了してるので問題無い
b.txtはHDDの書き込は失敗したがエラーが返ってきたのでosのメモリ上には残ってるので割と問題無い
ただ >>546 の方式だと a.txt は書き込み成功を返したにも関わらず
管理情報が書き込まれず消失するんだよね
成功返しちゃったからosのメモリからも消えてるよ
b.txt に関してはエラーが返ってきてCMRと同じになるけど
やっぱファイル書き込み毎に管理情報も更新しなくちゃ駄目じゃね？ >>559
ファイルの書き込みごとに管理情報も～という点に異論は無いけれど、
少なくともシーゲートは書き込み時の安全性をメディアキャッシュのメリットとして挙げているよ。
宣言文句なだけなのか何かしらの根拠が有るのかは知らないけれど。
で、対CMRは別にしてメディアキャッシュ内での書き込みの際に代替セクタ情報をどこに置くのがリスクが少ないのか？
という想定で考えた場合、そのトラックで終わる場合と別の管理領域までシークして書きに行く場合とで
どっちがリスク高い？
自分はトラック内だと思ったからの想像だったんだけど。 シーゲートの前モデルはCMRだけどメディアキャッシュ搭載だってのに
脳内のSMRを語るのもいいけど、現実の商品展開を見なよ 最近のSMRドライブのDRAMキャッシュが多めなのは、「メディアキャッシュの配置情報を全部DRAMキャッシュに乗せとく」ため、
みたいな理由もあるのかもね。
電源断でDRAMキャッシュが飛んだ状態で起動したら、最初にメディアキャッシュ内に書かれている配置情報を読み込みにいくとか。 >>561
実機はよく知らないが、4K物理セクタ移行期の512B LBAな論理セクタ対応のHDDとかだと
バンドサイズ4KのナンツーカミニSMRみたいな感じで元セクタデータを読み出し保存とか
あっても不思議ないかもねえ。今は論理セクタも4K移行済みのようだから両端の端数セクタの
マージ処理はまじ不要かもしれないけど。 >>556
妄想的に言えば、やっぱりテーブル参照でしょ。ヘッドシーク時間惜しいし。
メディアキャッシュの処理順はFIFOじゃないかなあ。FIFOのポインタを参照すれば
メディアキャッシュ上の空きエリアの先頭セクタを直に知ることになるし。 Ultrastarの7k8だかにはメディアキャシュと不揮発メモリ両方の搭載をアピールしてるんだね。
シーゲートMTCではホワイトペーパーでは言及しつつも実装例の話が出てこないし、
7k8の性能が気になるな。
WDはメディアキャシュと不揮発メモリはどう使い分けるんだろ。 >>561
脳内はお前な
DRAMじゃなくて残るのなら
NANDでも使ってるのか？
そんなチップがのってるソースが欲しいわ メディアキャッシュから書き戻す余裕も無いほどの負荷で、継続して読み書きし続けていたら、
SMRの性能低下は避けられそうもないですな。
逆にメディアキャッシュから書き戻せる程度の書き込み頻度や量なら、ランダム書き込み性能が向上したりするかもしれないと。 >>563
感覚的な概数に過ぎないけど、まだ今出てる機種の半分くらいは512e、すなわち512セクタをエミュレートしてる
残りの4割が4Kn、1割が512n
>>566
SRAM知らないとかねーわ >>568
SRAM wwww
ボタン電池とか入ってるのか？ >>560
なんだ、メディアキャッシュ上で複数ファイルをシーケンシャルライトするのは諦めたのか？
メディアキャッシュが安全なんてのは見当もつかないがソースはどこだ？ 民間療法を信奉する素人みたいな推測の域を出ないなあ いやいやお前ら目を覚ませ
メディアキャッシュなんてただのCMRの外周だぞ
メディアキャッシュでできる素晴らしいアルゴリズムがあるならCMRでも出来るだろうよ
ただ外周だから何もしなくても普通のCMRよりは性能は良いだろうよ 4Knなんてエンプラしか無いでしょ
コンシューマは512eしか見ないわ >>572
ま、HDDなんて単なる消耗品ですからねー
10年どころか3年保てば御の字でしょ。 ユーザー側が、メディアキャッシュすっ飛ばして本体部分に直書きさせろ
っていうコマンドを使えるようにすれば、問題のかなりの部分は解決するような気がする > SRAM wwww
> ボタン電池とか入ってるのか？ 変な引用しちまった
キャパシタ知らんとは思わなかったな >>572
だからCMRでメディアキャッシュ備えた機種はとっくに出てるって
その浅い脳のシワに刻んどけよ >>580
検索しなよ
シーゲートの広告記事になってるから 結論
SMR方式のHDDであるST4000DM004を実際に検証してみて，たしかに従来の方式よりも確実に
遅いものの，問題のない速度であるという判断に至りました。もっとも，書き込みだけであって
読み込みであればまた別の話ですが。
ランダムアクセスはSSDに，大きなデータはHDDにという傾向は今後も一層強まるでしょうから，
容量的に有利なSMR方式のHDDを避けて通るのは難しくなっていくでしょう。あとはタイミングだけです。
というわけで熟慮に熟慮を重ねた結果，ST8000DM004を購入してバックアップ用のHDDとすることにしました。
第556回 SMR方式のHDDでも実用できるか検証する
https://gihyo.jp/admin/serial/01/ubuntu-recipe/556?page=2
------
まあ、こういうレポライターが此処の住人ではない。なんてことはナイのでしょうねえw おまえら朝からずっとやってんのかよ
怖すぎるわさすがに >>578
キャパシタってｗｗｗ
全然持たないじゃん
嘘ばっかり
>>579
それがあっても何の根拠にもならん ・windows入れてアップデートが遅くならないか
・windowsのテンポラリがSMRドライブ上にあるとき圧縮,展開は遅くならないか
・CMRに比べてデータの保持期間は同等か
・同時に幾つまで録画可能か
このあたりを検証してほしい ベンチマークはメーカが対策をたてているから性能差が潜在化している >>570
とりあえずメディアキャッシュのPR記事ね
https://weekly.ascii.jp/elem/000/000/415/415975/index-2.html
こういったメーカー主張に沿ってそれを実装を想像し
メディアキャッシュはランダムライトをシーケンシャルに処理できるから高速化する
という仮定の実現手段を具体的に想像してただけだよ。
自分はもともと>>528のように
シーケンシャル化の可能性を検討しているに過ぎない。
>>545にも書いてるじゃないの
>>572を見るとヘッドアームのシーク時間という概念が無いようだから
話が通じてないようなのはわかったけれど。 >>590
そんなんお前環すぎて確約出来るわけないやん
そんで、例えば(数字適当)4同時録画なら90％の確率で問題ない とか言われても困るでしょ？
SMRの問題は極端に低下する可能性があるって事でソレを許容できるかどうかってだけ >>590
同時録画数はwowowな24mbps 二放送まででしょ。普通は。 6MB/s。
3番組以上を同時録画できる家庭用録画機、液晶テレビはほとんど無いよね。
USB2.0規格で十分すぎるレベル。 >>592
DIGAの全録機は同時に６ｃｈの24時間フル録画＋１ｃｈ分の通常（予約）録画ができる
つまり７ｃｈ分のリアルタイム放送を24時間連続してHDDドライブ側の遅延なく書き込める必要がある
これはオマ環ではなく、DIGAの全録機をもつ全員がほぼ同じ環境である
impressの実証記事では、同時録画をたったの24時間行なっただけで。SMRは録画にも問題なし！と結論付けて、
あまりに杜撰な実験に、俺から顰蹙を買ってしまった >>592
HDD一台で4放送同時録画できる録画機とか液晶テレビってある？ 型番メーカー名ヨロ。 >>593
DIGAの似非全録機種BRGシリーズは６ｃｈを同時にDRで録画する >>597
地上波 地デジはmax 16mbps だから。 三放送で48mbps最大。 DIGAの似非全録機種BRGシリーズは6チューナ搭載で通常(予約)録画６ｃｈ分、もしくがチャンネル録画(8時間制限)６ｃｈ分を同時録画できる。
この機種の酷いところは、通常（予約）録画で圧縮モード（5倍録など）を設定していても、録画時には一旦DRで保存して、
アイドル時間にDR→指定圧縮モードへ変換を行なう。 つまりフルに使っていると24時間HDDはDIGAから書き込みをされていて、
もしHDDがSMRドライブならSMR内部処理に専念する時間がないのである >>597
最大三放送同時録画まで見たいですねえ
----
USBハードディスクに同時録画はできますか？（ディーガ）
チューナーを３個以上搭載しているディーガ
通常録画で同時に録画可能な番組数は、 最大３番組となります。
＊SUZ2060、SCZ2060は最大3番組まで同時録画ができますが、「4K放送（BS4K放送／110度CS4K放送）１番組＋ハイビジョン放送２番組」または「ハイビジョン放送３番組同時」の同時録画となります。
4K放送（BS4K放送／110度CS4K放送）を受信できるチューナーは１つですので、4K放送の複数同時録画はできません。
２チューナー搭載ディーガ
同時録画可能な番組数は、最大２番組となります。
１チューナー搭載ディーガ
録画しているときは録画用として使いますので、録画中の番組のみ視聴可能となります。
・USBハードディスクに複数の番組を同時録画するためには、USB3.0対応のUSBハードディスクをご使用ください。
http://jpn.faq.panasonic.com/app/answers/detail/a_id/41997/~/usbハードディスクに同時録画はできますか？（ディーガ） 全角野郎だぜ？
MbpsとMB/sの違いも知らんのだろう >>591
だから俺が >>442 で言った通り書き込み先がメディアキャッシュというプラッタの外周の一部に
限定されるからランダムライトでもシークが短く済むだけって事だろ
というかちゃんと記事で説明されてるんじゃねーか、ちゃんと読め >>602
って嘘。記事には直接はそう書いてはないな
記者自身「効率化を図ってるそうだ」って言ってるから良くわかってないんだろうな
メディアキャッシュに再配置場所を書く事なんてHDD利用者からはどうでも良い話なんで
多分記者も勘違いしていて実体は再配置場所を書く事によりメディアキャッシュという
狭い範囲にランダムライトを限定出来るからシーク時間を減らせて高速化されるんではないかと 総量によるけど、差分バックアップならともかくフルだったらあまり使いたくないなあ
>>582
rsync使ってみたのか
ウチはネットワーク転送用に1ファイル終わるたびにベリファイかけるオプションにしたら、死ぬほど遅くなってfsがそれより低レベルでおかしくなったんだよな……
>>588
根拠？
あんたが現実の商品を知らんかった事の根拠になってるよ >>603
その効率化の一環としてシーク減少による高速化に加えて
何かやってるのでは？シーケンシャル化してるのでは？という仮定の話だよ。
スレでもシーケンシャルでって考えてる人からのレスがそれなりに付いてるでしょ？
せっかく物理的な位置を無視して書けるんだもの。
一気に書いて効率アップをと考えても不思議じゃない。
それに乗れなかったようなのでレス付けてすまんかったね。 >>595
例・数字は適当って言ってるやん。揚げ足取りにもなってないよww
普通に読んだら「保証できるわけ・するわけ無いから回答するならこんな言い方になるけど、そんなの聞きたいか？ 」以上の意味はないって分かると思うが解んなかった？
ああ、最低xM迄落ちる可能性がありますって言い方なら出来るか。…数字忘れた…seagateで数M、WDは一桁位マシなんだっけ？
>>594
たったの24H…w
そんなんで良いと思うなら、削除しまくって汚れたら…とか考えなかったんじゃねww うちはガラポンTVに、2.5インチで3T SMRなHDDをつないで使っていたら、
何日間は動いているんだけど、最後は書き込みエラーになる。
何度か試したけど同じ結果。たぶん断片化が進むと厳しくなるんだろう。
仕方がないから2.5インチで1T CMRなHDDに交換したら何か月動かしても
問題は発生しない。
試したのは結構前なので、最新のSMR HDDだと違うのかもしれないけど。 >>605
メーカーにとってメディアキャッシュへの書き込みをシーケンシャル化する必要性が無いんだよ
何故ならそもそもSMRはCMRよりサイズで勝ってるわけでな
だからSMRを売る為にはCMR以上の読み書き性能であれさえすれば良いわけ
で、SMRの低性能を誤魔化す為に用意したメディアキャッシュにランダムライトで書いたら
CMR以上の性能が出せたので既に目標は達成されてるんだよ
メディアキャッシュのランダムライトがCMRより早くなる仕組みが良くわかって無い？
ってシーク云々言ってるからわかってるとは思うがシーク距離は相当少なくなるから十分でしょ >>591
というかこの記事のメディアキャッシュがデータの損失を防ぐこと
が全然データ損失を防げる理由になって無いと思うんだが
手前の高速化の理由もあわせて酷すぎない？ >>605
その効率化についてなんだが記事をよく読むと再配置にかかってないか？
なんかその記事相当おかしい気がするんだが PCSX2とかのエミュレータのROMをSMRのHDDに置くのはヤヴァイですかね？
読み込み用途だけなら大丈夫でしょうか？ 数十GB～100GB前後のデータ大量に扱うのでうちの会社ではSMRは絶対無理
ここにいる最低な奴は、そういう用途を机上の空論などという奴
>>587、お前だよ
いい加減認めろや
SMRはオールラウンダーではない、用途によっては絶対に使ってはいけない >>612
なんで無理なんだ？メディアキャッシュ溢れるから？ >>608 >>610
あんたが相手の書き込み内容を理解してないだけに見える
（言ってることは同じだから）
>>615
溢れたら遅くなってその日の必要転送量に間に合わなくなるからだろうな 数十～数百ギガを「ランダムに」扱う用途ってどんななんだろうな
シーケンシャル書き込みはメディアキャッシュを透過するとされてるし、ここで力説されるのはランダムなんだろうが
そういうのって複数ドライブに分散して逃がしたりできんものかね >>618
ファイル共有、あれもう終わった？w
まあ実際ランダムに使うというかゆっくりDLし続けたりすると
メディアキャッシュは一生はけないんだろうな >>617
言ってることが一緒って頭おかしいな
>605はメディアキャッシュに書き込む際にどうにかしてシーケンシャル化
>610はメディアキャッシュからSMRに書き込む際の再配置の際の場所を最適化して効率化
全然違う 確かになかなか確実にメディアキャッシュを溢れさせる用途が浮かばないな
アンチの人なんかあげてくれよw >>620
あっ、そうなんか
>>608 最終段のほのめかし、
> メディアキャッシュのランダムライトがCMRより早くなる仕組みが良くわかって無い？
はランダムライトのメディアキャッシュ上でのシーケンシャル化ではないのかー
じゃあどういう意味なんだろう？ >シーク距離は相当少なくなるから十分でしょ
で分からないのか？ シーケンシャルと言っても次のトラックに移動する時はシークが発生するしな。
普通は渦巻トラックじゃないし。 >>626
次のトラックはシークの分を考慮してセクタがズレてるよ
それで連続してアクセスできるようになってる それくらいみんな知ってるよ。 回転待ち時間が減らせる。 >>622
>>473 の言ってる通りなんだけど
ランダムライトについては特にシーク距離の短かさが影響しそうだよな
例えば1プラッタ1TBで10GBのメディアキャッシュを設置したCMRに
osからa.txtの書き換えを依頼した時を考えてみる
もしメディアキャッシュの無い通常のCMRでファイル管理情報が最外周にあって
a.txtが最内周にあった場合シーク距離が最大になるけど
このシーク距離を100とする
管理情報の位置等を工夫すれば100シークする事はまず無いだろうが
どう工夫しても期待値で2、30はシークする事になるだろう
一方でメディアキャッシュがある場合は1TB中の10GBなわけだから
メディアキャッシュは外周部分の1%にしか存在しない事になる
osからの書き込みはメディアキャッシュでしか受け付けないので
当然効率を考えて管理情報も外周に配置するとa.txtの書き込みのシーク距離は期待値で1以下になる
つまりCMRだろうがSMRだろうがメディアキャッシュを置けば
ランダム書き込み時のシーク距離が既存のCMRの数十分の一になる
実際osから見てどの程度の性能差になるかは知らないけどそれなりに差は出そうに思えないか？ >>629
件の人もメディアキャッシュはCMRでも意味があると納得してくれたようなので、そこは問題ないです
あとは管理領域書き終えなかったら飛ぶと力説してる件ですかね
ジャーナリングと同じで、書き終えたイベント以降は捨てるだけなんですが、納得してもらえるかどうか…… >>630
管理領域書き終えなかったら飛ぶってどれの事だ？ >>621
アンチじゃないけど、著作権切れの映画を大量にトレントで落とそうとしたら激重でずっとHDDがカリカリ言い出したから古いHDDを引っ張り出してそこに移したよ。 うぇ
海門瓦6Tだが
Get-FileHashでドライブ全体のハッシュを取得していたらファイルシステムが吹き飛んでやがる
やけに早く終わったなって思ったらエラー吐いてて、そのファイルを見てみるとあるはずのディレクトリが消えたわ
一緒にやってたWD6Tはエラー吐いてないので、やっぱりsmrは何かしら信頼性が落ちるのかも分からん >>630
どこまでイベントを書き終えたか書いておかないとどこまで書いたかわからないので
管理領域ないしはイベント履歴的なものが書いてある最終まで戻る SMRのドライブでメディアキャッシュを経由しない書き込みをするには
SMRバンドのサイズ以上の連続データであることが条件なのはわかるけれど、
メディアキャッシュ＋CMRの場合はどんな基準で割り振ってるんだろうな？
ホストから流し込まれたデータを俯瞰してみて
シーク距離が多そうな場所をメディアキャッシュにってくらいしか想像できないけれど。
ヘッドが内周にいる時にはメディアキャッシュのほうが遠いってこともあるだろうし。
そもそもメディアキャッシュの位置が外周とは限らないか。
ドライブ全体に対するシーク抑制という意味では中腹のほうがよさそうだし。 >>618
ギガをランダムって書くと違和感だけど、ギガの書き込みを複数並列でなら個人用途でもある人はあり普通に居るよ？
コンピュータ使うのって 定形化して自動化・仕事をやらせ、人は頭を使う事に集中するのが目的であり、今時のは「PC」レベルでも複数の処理をやらせてもこなしてくれるから、数十～数百ギガまで行かんでも大きめの書き込み並列発生なんて俺でも結構ある。
PAD・スマホで事足りるコンテンツ消費ダケならそんな事無いだろうけど、PC使ってるって事はPADじゃ足りない事も想定するだよね？
618ダケじゃないけどさぁ…使い方は人によるってのを認ないような書き込みってなんなん？ >>632
お前の方式だと >>559 の場合に a.txt は消えないの？ >>636
ドライブ全体のシークというかメディアキャッシュから再配置する際のシーク時間を考える必要性ってある？ >>633
やっぱりメディアキャッシュを溢れさせる用途ってファイル共有位しかないんかね >>637
だよな
様々な用途を想定出来てないガキが草生やしながら
「例を挙げてみせろ」なんて片腹痛いわ >>637
ギガ書き込みを並列に書き込む場合CMRだとどうなるんだっけ？
かわりばんこに書くんだっけ？ >>637
根本的な話としてまっさらなバンドに書く場合に限りCMRの連続したセクタと同じように書けるよな
だからメディアキャッシュを使わない書き込みなんてのも出来るわけだからな
例えば1GBのファイルをバンドに直接書く場合1GB分の連続したバンドに書くんだろうけど
それは当然連続したセクタでもあり
CMRの連続したセクタと本質的に同じものと見なせるでしょ
だから別にギガの書き込みが並列だろうとバンドでもCMRのセクタと同じように書けると思うけど
1GB2個並列の場合1GBの連続したバンドを2箇所確保してから書くだけの話で
それはCMRで1GBの連続したセクタを2箇所確保してから書くのと変わらないでしょ >>637
だから、「結構ある」なら具体的に例示して欲しいと思うんだがなあ
無いのを示せってのは悪魔の証明要求ぞ？
議論の想定として、メディアキャッシュをフラッシュする暇もないほど大量のランダム書き込みが連続するってことにはなると思うが
個人でそんな大容量となると、動画（これは多分シーケンシャルで扱えるよな）以外だとそれこそファイル鯖くらいしか思いつかんし、ファイル鯖用としてSMRディスクが売られてる例あったっけ >>638
書き終えずに不具合が出れは、成功と返すことも無い
無いから元の場所にa.txtとやらは残るよ
ジャーナリングと同じって何度も書いてるやん
いいかげん理解しろよ >>644
> 悪魔の証明要求ぞ？
変なキャラ作っててキモいなｗ >>644
「普通は問題ない」って言いたいんだろ？
巨大PJのbuldでも、kernel等々のmakeでも、raw画像でも、4k8k動画でも、imgやDBのスナップショット取得でも、gitの更新・定期cloneでも、バックアップでも、torrentでも、TAT向上のためのキャッシュ更新系システムでも、readメインだけどbit化け対策のチェック系システムで
普通なんて人によるって言ってるダケなんだが、なんで理解できないの？
さっきも書いたがpadで事足りるようなコンテンツ消費以外にPCを有効活用しようと思ったらネタなんて人それぞれ色々あるんだよ。 >>644
おっとカッカして読み飛ばしてた。動画とファイルサーバ だけ？
なるほどww SMRドライブの動作の推測から考えて、
・連続したデータをSMRバンドサイズごとに区切れた分以外はみんなメディアキャッシュ行き
・ドライブファームがシーケンシャルとして拾ってくれなければメディアキャッシュ行き
こうなるよね？
ドライブファームは送り込まれたデータからしか判断できないことになるし、
DRAMバッファにため込まれた範囲でしかシーケンシャルの判定ができないはず。
結果的にどんな大きなファイルになるんだとしても、
OSがファイルサイズから書き込みセクターを調整したとしても、
データがDRAMバッファに収まる範囲で連続してこなければシーケンシャル扱いはされないはず。
こうなると思うんだけど、違うかな？
データストリームAとBとして並列で書き込んだ場合を想定すると、
DRAMバッファ内にはAとBのデータが混ぜこぜになっていて、
ドライブファームがそれぞれのデータをSMRバンドを埋めるに足る量だけ
連続データとして見つけることができればSMRバンドに直接書きに行けて、
見つけられなければメディアキャッシュに格納されてしまう。
DRAMバッファが大きいほどシーケンシャルに書きに行ける率が上がる。
となるのかな。 spotify使うとメディアキャッシュ溢れそうだぞw 流石にもう直ってるのかね
ttps://gigazine.net/news/20161111-spotify-write-junk-data/ あ、SMRバンドごとの先頭に該当するセクタの書き込みからバンドサイズ分が連続しないとだめなのか？ >>650
じゃあCMRの場合はどうなんだ？
>>643 にも書いたがバンドだって結局連続したセクタの一種でしょ？
CMRだってシーケンシャルライトの時は連続したセクタを確保して書くわけで
シーケンシャルライト時はSMRは連続したバンドを確保して書く
CMRは連続したセクタを確保して書く
バンドは連続したセクタの一種なので結局差異は殆ど無いと思うけど？ >>650
嘘。言ってる意味がわかった。サイズ未定のものを書く場合か。確かにSMRは苦手そうだな サイズ未定を書くといえばテレビ録画だよな
あれ結局どうなの？具体的にパフォーマンスの限界を示したメーカーとかないの？ >>654
１個のバンドの中に複数のセクタがあり、ドライブ外部からはバンドが全く見えずに
セクタしか見えない状況でPC側がアドレス指定して書き込み命令を出すわけだから
PC側にとっては未使用セクタへのシーケンシャルライトのつもりでも
「未使用セクタ」と「使用済セクタ」を含むバンドへの書き込みは
ドライブ内部で「使用済セクタ」部分のデータをリードしてコピー保存しておいてから
バンドを書き換えるというシーケンシャルとは呼べないアクセスになるんじゃ？ >>655
録画用途だと大したストリーム数は維持できなさそう、てのは前から言われてたよ 長期間このスレを読んでいるとSMRを実際に使ってこういう理由でダメだったという書込は全スルーしてます。
とにかく、信用できない、サンプル数が少ないとか言って、なんとかSMRは汎用性があってメディアキャッシュ最高！っていう流れにしたがりますw >>658
つまりCMRでのシーケンシャルライトではosがHDDのセクタ一個一個洗って
シーケンシャルに空いてる領域見つけてそのセクタ一つ一つに対して書き込み指示をHDDに出してるって事？
俺はそんな面倒な風にはなっておらずHDDに対してのシーケンシャルライトの指示は
パスとデータとサイズを渡すだけで良くなってると思うけど >>659
HDD内のファイル1個更新する毎に全然別の場所にある
不揮発領域にあるジャーナルファイルの更新も必要なわけでしょ
全然シーケンシャルライトにならない気がするけど？ >>652
resそんだけかい。急にアンカーもやめて…見逃す所やったやろが
お望みの例は一杯書いておいたから、個別事例が重要だと思うなら全部論破しといてね。まぁマジメに考えたら他にも一杯あるんだろうが
こっちの論は単に「普通なんて人による」ってダケ。PC特にSMRのような仕様だと、おま環や使い方への依存がキツイいから「普通は問題ない」って言うのは物凄く難しい os側に実装されたファイルシステムを理解して処理出来るドライブ
実装が想像つかない >>666
そうだな。だから普通はファイルシステムはHDD自身に定義されていると思うが
そうなってない特殊なHDDに遭遇したのか？ そんな認識だからドライブ内のデータ処理の話にファイルを連呼してたんだな。 >>668
なるほど。例えばNTFSでフォーマットしてるのはosか
でもメディアキャッシュなんて異端なものが入ってる以上旧来のNTFSの書き込みなんて出来るわけもないから
多かれ少なかれHDD内で改変、エミュレート的な事をしてるんだろうな >>664
ジャーナリングはログの使い方に関して似ているから持ち出したんだよ
ジャーナリングはファイルシステム上で、ライトキャッシュ関連のイベント、物理的には磁性体上
イベントログはデバイス上の不揮発性メモリ
これ絡みで約十年前のロック騒動知らない？
両者はレイヤが違う
いい加減覚えてくんないかな～ ファイルを扱えるってことは情報機器ではものすごく便利で大切で無くてはならないものだけど、
なぜ"ファイル"って形になって存在してるか、意識してる人は少ないだろーなぁ。
そこいらへんのビットの塊があーだこーだして、人が使うときには"画像ファイル"やら"テキストファイル"
やらに見えてて、使う人の要望に応じて使える事実。
先人たちの様々な積み重ねが、何十年も経て今の形になってることに感謝しなきゃ。 >>671
>イベントログはデバイス上の不揮発性メモリ
これのソース出して
ディスクに書いてたものをこういうものにするならいづれにしても追加の部品が必要になり
コストアップになる もともとはファーム格納してあった不揮発メモリの一部じゃない？
今はファームはディスクからRAMに展開のようだけど。
フラッシュメモリより前の時代から有る機構だろうからEEPROMとかの >>671
レイヤがどうであろうがa.txtとb.txtを不揮発領域に書く間に
他の不揮発領域を読んだり書いたりしたらシークが発生して
シーケンシャルライトでは無くなると思うけど
そんなことが出来るのか？ 今の時代的に言えばSoCに不揮発なメモリをちょっと積んでてもおかしくないな。
ファームロックの時の修復の仕方から考えても、ジャーナル領域はディスク上には無いんじゃないかな。
基板とディスク側の接続を切り離した状態で基板起動してクリアしてたみたいだし >>671
ああ、不揮発メモリを追加で用意するのか！？
いや >>608 に書いた通りメーカーにはSMRのランダムライトを早くするモチベは無く
SMRは安さが売りだからそんな事にコストはかけ無いと思うけど ちょっと混乱しそうだから修正
ジャーナル領域→ロックの原因となったログ領域
ログが320個の状態で電源落ちると次回起動時にロックする不具合だったよね。確か。 >>678
それが何故不揮発メモリだから起きたのかっていうのはわからんが >>679
ファームのバグで起こった不具合、
揮発メモリなら次回起動してもログが無い状態で起動だから発症しないってことじゃない？ >>676
ロックファームの件を調べたら
基盤と本体を分離するのは起動時に本体のデータを読んでロックかかるのを防ぐため
そのあと基盤と本体の接点をつないでスピンアップさせてから操作してるんだから
(clears G-List と Format user area partition without certifying defects and relocate defects. not effect Data in a drive）
ディスク上のデータを操作してると考えるのが普通 >>681
うお
最後に繋いで消してたか。
自分でも2台やったはずなのに憶えてなかったわ。
失礼しました。 >>668
多分ファイルシステムに関係無くHDDの標準機能として
指定したサイズが空いている連続領域の先頭アドレスを返す位の機能は提供されてるんじゃないか？
それ位はラップしといてくれないとメディアキャッシュもバンドも実現厳しそうな気がするが >>683
いや、それも無いはずか
HDDの管理情報を見ればどこか空いてるかosがわかるから
HDDがどこが空いてるか返す必要はないはずで、、、
バンドにシーケンシャルで書くって相当難しいというかなんか無茶してるのか >>658
ちょっと調べてみたら確かに言う通りっぽい、そう簡単にはいかないようで
じゃあバンドにメディアキャッシュ経由せずにシーケンシャルに書くってどうなってるんだろうな 単純にPC側が書き込み指定してきたLBA指定範囲がある一定以上のバンドサイズ以上であったら直接書くんだろう
論理アドレスとHDD内の物理アドレスが別で空いてるところならどこでも書いて
論理アドレスの参照先にその物理アドレスを指定すればいい >>687
そのバンドの範囲のセクタが使われてるかどうかはHDDは知らないはずなんだ
何故ならファイル管理領域はosが勝手にHDD上に作ったものだから
揮発メモリと同じように >>688
まっさらのバンドか何か書いてあるバンドか書いてあるが論理アドレスを割り振ってないバンド（トリムが必要なバンド）かは
書き込み際にメタデータとして残してるでしょ TRIMコマンドで空になったバンドには、未使用フラグを立てるのか。 >>687
>>691
あー、なるほど、osには倫理アドレスしか見せなければ
HDD側では物理アドレスを割と好き放題出来るのか
って怖って思ったけどSSDのブロックを分散させて書くってのもそういう事なんかな >>648
バラクーダの箱には週40時間(8h*5)の運用で年間55TBの作業負荷率を謳っているし
それを大きく超えるような運用だとエンプラ向けを買えと言われて終わりじゃねえかな・・・ >>691
それにしてもトリムはosも対応してなくちゃいかんのだろ
テレビとか対応してなさそう >>681
ディスクのデータ操作はしてない
最初に基盤だけつないでるのは、基盤側におかしくなったカウンタ（エラーログのインデックスカウンタ）があるから >>696
SMRHDDはCMRHDDが使えるハードで使えないといけないから
ドライブマネージドでアイドル時にトリムされるだろう >>697
それなら基盤と本体を外す必要ないんだよなあ >>698
それは無理じゃね
そもそもosがファイルを削除する時ってHDDに対しては管理領域の書き換えしかしない
つまりHDDからするとデータ書き換えと同じ指示だからいつどの領域が解放されたのか全然わからない
だからトリムってosがHDDに対してどの領域を解放したか教えてあげるコマンドなんじゃないのか >>700
この場合はHDDが管理している部分だからそのtrimとはまた別でtrimというべきではないのかもしれない
SSDと違ってブロックの最初の方だけしか書いてなければ
書いてある部分をメディアキャッシュにコピーしてそのあとのアドレス部分も足してブロックを消してから書く
なんてことしないでも書いてない部分にデータを瓦書きできるから
ある論理アドレスのデータを書き換え指示があれば、適当なところに瓦書きしておいてあとでその物理アドレス
と論理アドレスを対応させる。
そうした場合、対応させる前にその論理アドレスと対応していた物理アドレスは不要なデータになる
この不要なデータになった物理アドレスリストを保存しておいて不要なデータが多くなって非効率になった？バンドにおいては
そのバンドの必要な(論理アドレスと対応している物理アドレス)データのみメディアキャッシュに入れてから
バンドの先頭から書き始めるとかそもそも論理アドレスと対応している物理アドレスを他のバンドに追いやって
空き領域の断片化に対応する >>701
後で物理アドレスと倫理アドレスを対応させる意味はわからん
というかそのまますぐ対応させないと書き換え完了とは出来ないと思うが
で、元の不要な領域を管理領域から削除するまでは書き換え処理の一環で同期的にやらないと不味いと思うが
書き換えについては大体そんな感じで出来そうな気はするけど
純粋な削除に関しては対応出来ないよな
で、対応出来ないとバンド内の適当なところがどんどん狭くなってこの書き込み方式が使えなくなる
そうなったら全部メディアキャッシュ経由になるだけだろうけど
そのためのトリムなんだろうな 削除ってosがやるファイル削除の事な
これは元々osが削除されるファイルが書き込まれたアドレスには何も指示を出さないから
HDDが把握しようが無いんだよね >>702
後でってのは書き込みの直後
>>703
一旦ゼロフィルさせてから使ったらどうなるんだろうね 丁度トリムについて説明してるサイトがあった
ttp://www.logitec.co.jp/data_recovery/column/vol_005/ >>704
問題は0か1かでは無く、その領域をosが使ってるのかどうかだから
0フィルとかしてもしょうがないと思われ メディアキャシュを経由せずに直接書きに行くための判断や処理のアルゴリズムなんて
SMRどころかその後のTDMRにも関わる重要な部分だし、
メーカー内部ではそうとう研究されてるんだろうね。
将来的にブロック書き込みの容量メリットが大きくなってきたら
ここの処理で大きくメーカー性能差(指向差)が表れそうだ。
今はまだSMRはシーゲートってイメージ強いし。
たまに出てくるWDのSMRの挙動は期待できると自分は思うし。 >>703
削除ファイルのデータ本体には普通何もしないから削除直後ならundelete可能なのよね。
削除云々はHDD外周部の12%強を占めるMFT(Master File Table)というディレクトリ管理エリアに
1KBブロックの1個のフラグを削除設定するだけ。Windowsのフォーマットでも同様。データエリアを
ゼロクリアしたりはしない。クイックフォーマットではMTAを初期化するだけ。ロングフォーマットでは
ただ単に全セクタとりあえず読み込みテストするだけらしい。だからフォーマットだけのHDDなら
痕跡辿ってファイルサルベージが可能。最近のHDDにはそんなサルベージ対策用にゼロクリア
フォーマット機能が付加されているらしいね。 >>708
じゃあどのトリムだ？お前が勝手に作ったトリムか？
いずれにせよ不揮発なストレージに対するトリムなんだから似たような
意味にならないとトリムとは言えない気はするが >>709
そのフラグを設定するのはosがしなくてはならないんだろ？
osの挙動を変えて良いのであればトリムの方が手っ取り早いと思うが
いずれにせよosに対してCMRでは不要だった操作をSMRでは受け付けるのであれば
その対応の有無によってSMRの性能はかわるって事だよね >>710
論理アドレスとの対応で不要になった物理アドレス先のことだよ >>712
そんなものはトリムなんて名前をつけるまでもなくHDD内で要らなくなった瞬間に削除するなり
再配置して整理するなり好きにすれば良いわけで
問題はosがファイル削除した時の話でわかってないなら
>>705 をちゃんと読んだ方が良いよ >>713
再配置に時間がかかるからそういう管理してるわけで
>問題はosがファイル削除した時の話で
こっちはSSDと違ってブロックを追記でき、
またそのバンドに必要なものが一切なければ消去する必要なくバンドの最初から瓦書きするだけなんだから
問題にする必要がない >>709
いい加減にOSとデバイスのファームで見る景色が違うことくらい把握しとこうぜ >>714
ファイル削除時に発生する問題はそんな話では無く
HDD側で自身のその領域が解放された事を知る事が出来ないって事
例えば100GBのSMRにosが100GBのファイルを書きました
そしてosはそのファイルを削除しました
その時HDD内の倫理物理アドレス管理上では100GB使用状態のままになってるでしょ？
当然次のバンドに直接書くための適当な領域は確保出来ない。そういう問題 >>717
だからOS側で解放された領域かどうか知る必要がないってわけよ
アイドル時に断片化の対応がされていたなら
次に角場合に小さいものならメディアキャッシュに書けばいいし
でかいサイズを書き換えるなら当然そのバンドは空くんだからそこに書くだけ >>717
>>HDD側で自身のその領域が解放された事を知る事が出来ないって事
そんなのHDD自身が知る必要なんて無いのに。 >>718
だからosが作ったファイルシステムとは別にHDD自身がどの物理アドレスが使用されてるか管理するんだろ？
その場合 >>717 の例の後のHDD自身の物理アドレス管理状態上の使用状況がどうなってるか考えてみって
100GB使用中になってて断片化整理のやりようも無いでしょ >>719
メディアキャッシュを使わずにバンドに直接シーケンシャルライトする場合の話な
そんな無茶しなければHDD自身がそんなこと知る必要は無いと思うよ >>720
何のためにメディアキャッシュがあるんだよ >>722
そもそもがメディアキャッシュを使わずにバンドに直接シーケンシャルライトする時の話な
>>720 の状態になったらメディアキャッシュ使って書くしか無くなると思うよ >>722
お前 >>718 当人か！
いや、だからファイル削除によって開放される領域をHDDが把握出来ないから
100GB丸々空いてるのに1GBもバンドに直接シーケンシャルライト出来なくなるSMRが完成するだろって話
しかもそのosに接続してる限り永続的に
それを防ぐ手段がトリムコマンドって事 >>721
WDのダイナミックアロケーション方式だと、メディアキャッシュなんて
そもそも不要かもしれないね。詳細は不明だけどさ。
メディアキャッシュ自体は、キャッシュ。STLつーかSMR領域の某セクタ＠バンドと等価であるべき。
という使命を恒常維持すべくファームがアイドル時に上書き更新しているだけなのね。海門の場合は。
ファイルというような概念はOSが夢想実装しているだけ。HDDは無頓着なのよねえ。 >>724
なんか、無茶苦茶な印象。
NTFSとかextとかのディレクトリ管理についげ再勉強したほうがいいよ。 >>718
ツッコミどころを間違えてた
どうやってHDDはそのバンドが空いてる事をしるんだ？ >>728
NTFS なら MFTが空きエリアを管理している、
DOSとかWindowsMeまでならFAT。 OSが自分自身で管理しているのよ。 MFTもFATもHDD上にメモ書きされているだけ。 >>729
そうだな、それはosがHDDの空きを把握するためにやってる事で
HDDがHDDの空きを把握するためにやってる事では無いんだよな
だからHDDが自身のバンドが空いてるか、osから使われてないか知るためには別の仕組みが必要 そういえばWindowsはHDDがTRIMコマンド対応だと認識すると自動的に発行するようになるん？
TRIM対応はWDのドライブがしてるってことは、WDのSMR制御方式はTRIMが貢献するようなしくみなんかね。
シーゲートのドライブでTRIM対応の話は自分は聞いたことがないし、
TRIMはあまり効果が無いようなSMR制御をしてるんだろうか。 >>732
windows7以降はトリム対応されてるって事だからそういう事なんだろうね
で、そうそうSMRの中でもトリム対応してるのとしてないのがいるっていうのがドキドキだよな
なんの違いが出るのかさっぱりわからないっていう
俺はバンドへのシーケンシャルライトが機能するかしないかじゃないかと思ってるが
そうだとしてもその違いを一般にどう説明するのか色々難しいという TRIM対応してないシーゲートのドライブでもシーケンシャルでメディアキャッシュのスルーがあるんだし
ただの制御方式の違いなだけだと思うよ。
全てメディアキャッシュ経由の書き込みになるんなら、
数十GBの連続書き込みであっという間に超低速状態になるはず。 >>733
↓のことかね。WDのSMRはダイナミックマッピング方式。それはバンドを書き換える場合、上書きせずに
空きバンドに書き換えデータと元データをアペンドした新バンドデータで書き換えた後でバンドの順序を示す
マッピングテーブルを書き換える。この方式だとHDDのデータ書き換えが進むとバンドの順序がランダム化
してしまうから、シーケンシャルデータの配置も実質断片化が激しくなって低速化する。
そこでトリムコマンドを実行することで本来あるべきバンド位置に別アドに更新書きされたバンドデータを
書き戻して、実バンドが LBA的にインクリメンタルに再配置するようにする。ということみたいね。ガベコレの一種。
こういう理解が正しいかどうかは定かじゃないがw こんなHDDでデフラグしたら、終わるんだろうか？
TRIM Command Support for WD External Drives
https://support.wdc.com/knowledgebase/answer.aspx?ID=26014
TRIM/UNMAP is supported for external hard drives with SMR (Shingled Magnetic Recording)
drive inside, like SSDs, for dataset management and to improve SMR performance over time.
One of the shingled write benefits is that all physical sectors are written sequentially in a
direction radially and are only rewritten after a wrap-around. Rewriting a previously written
LBA (Logical Block Addressing) will cause the previous write to be marked invalid and the LBA
will be written to the next sequential physical sector. The TRIM/UNMAP enables the OS to
inform the drive which blocks are no longer considered to be in use and can be reclaimed
internally by the HDD to ensure that later write operations perform at full speed. >>723
そうならないように満タン近くになったらSMRにもメディアキャッシュにも両方にデータが存在するアドレス
のSMR側を使えばいい
そんなことしなくてもメディアキャッシュにシーケンシャルに書けるならそっちの方が速いが
>>724
ならない
100Gも書けばSMRにもメディアキャッシュにも両方にデータが存在するアドレスが大量に存在するから HDDでもtrim対応してるのがあるみたい
これはSSHD(恐らく非SMR)
ttp://revimg03.kakaku.k-img.com/images/Review/000/354/354236_m.jpg
WDのSMRHDDだがこれはtrim対応表記はない
ttp://i.imgur.com/jNhmxhM.png >>734
ただの制御方式の違いでトリムがいるいらないがあるなら
トリムがいる方が完全に劣化版となってしまうけど
そんなにWDって駄目なメーカーなのか？ >>738
空きセクターへの再マッピングが必要の無い制御方式をシーゲートが取ってるだけだろ >>735
引用英文の終わりの方で不要になったバンドはOSがHDDに知らせて解放する。みたいな
ニュアンスでかかれているみたいね。DM-SMRの枠外仕様っぽいから要専用ドライバ？
SATAのホスト制御に関わるレジスタ設定やコマンド類は↓の仕様書に一般概要があるけど
IEEEみたいな厳密仕様じゃなく、詳細はメーカー任意なのだそうだ。ドライブ個々にユニークな
コマンド設定などが可能。ということ思いたいね。
Serial ATA Advanced Host Controller Interface (AHCI) 1.3.1
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf >>736
一応もう一度 >>717 をよく読んでほしいが 100GB の SMR に対して
os が100GB のファイルを1個書いてすぐ削除した時の話だよ
os側では当然100GB空いてるってなるけど HDD 内では100GB使用されたままって認識になってるはずだよ
何故ならosはファイルを削除した時にHDD上に自作したファイルシステム内にある
管理情報を書き換えるだけで良いので
HDDに対してファイルを削除したって教える必要がないから
それを教えるコマンドがトリムコマンドって言うらしいよ
メディアキャッシュにシーケンシャルライトすれば早いのは当然で
じゃあなんでバンドに直接シーケンシャルライトする必要があるのかって言ったら
メディアキャッシュが有限だからだよメディアキャッシュにシーケンシャルライトしてったら
すぐにメディアキャッシュが埋まってとんでもないパフォーマンス低下を招くからそれを防ぐために
バンドに直接シーケンシャルライトしようとしてるんだよ >>737
WDのはダイナミック・ハイブリッドSMR HDDは一台のドライブをCMRでもSMRでもその混在でも
設定次第で自由にわりあてられるみたいね。書き換え頻繁なホットデータはCMR。ほとんど
書き言い換え不要なコールドデータはSMRでとか。
Dynamic Hybrid SMR
https://blog.westerndigital.com/dynamic-hybrid-smr/ >>725
> ファイルというような概念はOSが夢想実装しているだけ。HDDは無頓着なのよねえ。
なんで人に言われたことをオウム返ししてんの？
しかもファームウェアって言葉が出てこないしｗ >>744
類意せ同意フォローしているだけですよ。あーあ。 >>740
そうだとして両者の性能が変わらないならトリムが必要な方が劣化版にしかならないでしょ >>746
CM大の論文では、WD方式は通常は早くないが、海門のような激遅モードには落ちない。そうです。 >>746
あなたが劣化だと思うのならそれは否定しないよ。
そう思えば良い。
自分はtrim使う方式を選んだのはただの選択の結果だと思うけどね。
今後も製品が出続けていったとして、何かしらの一つの方式に統一されたのなら
それがベストだったと結果的にいえるとは思うが、
現時点ではまだ優劣なんて付くもんでもないだろう。
むしろ後発のWDの方がより用途適正の高い仕様になってる可能性もある。 >>745
あーあはこっちのセリフだｗ
なんべんもマジェマジェしては
・fs(OS)がどうやって空きバンドを知るの？
・firmware(HDD)がどうやってfsのメタな操作だと知るの？
って言われてはだんまりして、ほとぼり冷めたらまたマジェマジェしてたじゃん >>735
Trimコマンドでは、削除の際に生じる未使用領域をSSDコントローラーに対して通知する機能である。
って下記サイトにあるので少なくともos側はTrimコマンドではSMRに対しても
未使用領域を通知する以上の事はしない、というか出来ないと思うけど
それを受けてSMR内部でどう動くかは自由だけど
ttps://www.wdic.org/w/TECH/Trim >>749
はあ～ 誰に突っかかってるのさ？ 人違いw >>746
ここは747に一票
ユーザ側からの制御にメリットもデメリットもある
うちの使い方だと待機時間の方が長いんで安いんならWD側選ぶけどなー
>>751
なら同レベルのアレなんがいっぱいおるんやな! >>747
そうそう、詳細はともかくメディアキャッシュを延命するために
トリムを必要としたとか同等のメーカーが違うものを要求するなら
そういうトレードオフが無いとおかしくないかと >>742
まず1バンド分メディアキャッシュに書くだろ？
それ以降はそこが開くからそこに書くだけ シーゲートは元の位置に書き戻しじゃなかったっけ？
空きバンド使っちゃったらメディアキャッシュに退避されたバンドは
次の空きバンドが出来るまで元に戻せないような気がするし。
というかダーティフラグ立ててそのまま残るって話じゃなかったっけ？ >>737
SSHDならSSD積んでるんだからそれ用にトリムは対応するんでしょうね >>754
？？バンドに直接書く理由はメディアキャッシュを溢れさせないためでしょ？
バンドに書き込み済みのデータを逆にメディアキャッシュに移動しちゃったら本末転倒でしょ >>755
海門は 1 read 2 write。 WDは 1read 1write だそうですから。
WDのSMRはメディアキャッシュにバンドを退避しないでしょ。
というかそもそもWD方式ではメディアキャッシュ不要であるような気がする。 >>757
メディアキャッシュに書いた元の論理アドレスを割り振っていた元の物理アドレスのバンドが開くでしょ >>739
すまん
調べたらkakaku.comとかで載るような民生品ではまだWDは出してないみたいね >>758
メディアキャッシュ不要は無理でしょ
重要なのはユーザから見たパフォーマンスがCMR未満にならない事だからな
例えWD方式でランダムライトもバンドに直接かけたとしても
CMR以上になる気はしないし、なるならCMRで何故そうしないという話になるし >>759
そのメディアキャッシュに書いたデータはいつバンドに書き戻すんだ？ SMRは宇宙人の技術で、メーカーも仕組みをよく解かってないオーバーテクノロジーなんだよ！ 別にCMR以上のパフォーマンスに拘る必要なんて無いでしょ
価格や容量など全体で見て判断されることだし、
メーカーが仕様を選んで製品として仕上げ、客がそれを買うか判断するだけのこと。 WDの方式にメディアキャッシュがあるかどうかと考えると、
バンドに追記できるかどうかで変わってきそうな気はする。
追記できるセクター構造ならメディアキャッシュ無しでも容量の残ったバンドにどんどん追記していけばいい。
物理アドレスの割り当てマップはかなりぐちゃぐちゃになると思うけれど。
追記の為のセクター間の隙間すらないようなぎちぎちのセクター構造なら
例えば1セクターの書き込みにもバンドの中のトラック一本消費する頃になるから
容量効率が悪すぎるのでメディアキャッシュである程度纏めてる可能性が高いと思う。
WDの3.5SMRはまだ青2TBだけだし情報不足な感じだね。
試しとはいえさすがに2TBを今更買う気にはならんし。 >>764
客に選択権があればいいんだけど
CMR/SMRのどちらなのかを秘匿してたり
SMR製品が消滅してたりという状況なので
SMRが嫌なら「SMRかもしれないけど実はCMR」を買わずにSSD
という選択肢しか無い現実……orz >>762
アイドル時に戻せばいいだけで不都合ないでしょ >>767
どこに戻すんだ？HDD内で管理してる物理アドレス上は
全アドレス使用中になってる話だったろ？
osのファイル削除が検知出来なかったから >>764
逆にメディアキャッシュさえ置いとけば簡単にCMRのパフォーマンス超えるのに置かない理由がわからんが
シーケンシャルライトさえメディアキャッシュに乗らないようにしたら
メディアキャッシュ溢れさすなんて起こすのが難しいレベルの話になるでしょ シーゲートとWDでアルゴリズムが違うのか
どっちが良さそうなんだろうね >>770
仕様を選ぶのはメーカーだという話
CMRを超えないといけないというあなたの中の判断基準を否定はしないが、
同意できない場合も有るということ。
メーカーがCMR超える性能を約束したような出来事でもあったのか？ >>769
なにをいってるんだよ
1-100バンドのHDDに1-100書いて消してまた1-100書くときに
1バンドのみメディアキャッシュに書いて2-100は順次SMRに書く
すると100に割り当てていたバンドが開くのがわからないの？ >>773
よくわからんのだが例えばosが再度任意のアドレスから10GB書き込み依頼したらどうなるんだ？
メディアキャッシュ使わずにバンドに直接書けるのか？ >>772
約束なんてするまでもなく
「新製品のSMRは既存のHDDよりサイズもパフォーマンスも上回ります」と
「新製品のSMRは既存のHDDよりサイズは上回りますがパフォーマンスは下回ります」
だったら絶対に前者のほうが売れるでしょ
あいつら営利団体だから儲かる事しかしないよ？
サンタさんじゃないんだよ 無難なところで納めるという選択肢もメーカにとっては十分価値あるだろう。
ドライブ内部の処理能力は基本的に有限だ。
営利企業である以上は売れることを追求するのは当然だが、
現状のドライブマネ―ジドSMRの販売価格帯に見合うコストしか掛けられない。
なんでもかんでも高性能を追求するだけが判断基準ではない。 >>772
ないねー
消費者は容易に区別出来るようにと要求する権利がある。無論メーカに表示義務はなく非表示で売上に影響なければ原価が安い方にするのが資本主義の論理。 ベンチをして判断するしかないな。
SMR向けベンチが作られ、それを騙すSMRが開発され、、、いたちごっこに つまり週40時間、年55TBを越えるワークロードが掛かるか否かだろ？
それを逸脱しない条件で性能が出なけりゃそん時文句を言えばいいじゃないか
わざわざ逸脱させるベンチになんの意味があるよ >>781
素晴らしい。SMRドライブのスクショとしたら理想的な動作をしている。このような性能が今後のHDDに求められていると感じた！ >>781
10MBも出てるからえらい
この前扱ったSMRは1MB切るうんこだったし 旧HDDから新SMR HDDに丸ごとコピーするときに、極端な速度低下は出ないようにしてほしいのは確か。
安価なSMRでも最低限そこがクリアー出来ないと倉庫用に使うのも厳しい。 >>776
あっちゃ～
773の「消して」の行為主体を曖昧にしたもんでワケ分かんなくなってるの？ >>785
行為主体も何もファイル削除時にそのバンドにはosもhddも触って無いから
消すも何も発生してないはずなんだけどね >>786
おやおや？
なら答えられるのかな？
>>787
うん
知っててつついてみた >>787
>773
みたらわかるでしょ
1バンドのみメディアキャッシュに書いて2-100は順次SMRに書く
キャッシュにも残っているバンドがあればキャッシュ側に論理アドレスを紐づけてから
1からかける >>789
例えばosからhddにバンド2の途中のアドレスから10GB書いてくれって要求が来たらどうなるんだ？ >>789
多分言ってる意味わかったー！ちょっと間違ってるとは思うが
確かにファイル削除なんか把握しなくてもバンドにシーケンシャルに書けるな >>791
例えばosから任意のアドレスに任意のサイズのデータを書いてくれとSMRに要求があったとする
SMR側としてはその書き込み指定された領域はバンド1ｰ5の5つのバンドにまたがってたとする
で、実はこの段階でバンドに直接シーケンシャルに書けない
瓦書きを意識しなくてはならないのはデータ終端を含むバンド5だけなんだよね
だからバンド5に書く分だけメディアキャッシュに書けば他は普通に
バンドに直接シーケンシャルで書ける
いやースッキリしたわ
そうなるとトリムって何の為に使うんだろうな >>790
HDDの外側からは論理アドレスで指定してもHDDが実際どの物理アドレスに書いてるかわからないし
バンド構成がどうなってるかもわからない >>793
お前の言ってるのは >>792 って事じゃないのか？
まあ俺的には解決したから良いんだけどな 「データ書き込み時、書き込みの終端となるバンドに含まれるデータはメディアキャッシュに書く
そうでない物はバンドに直接書く」
SMR内の書き込みルールって割とこれだけで全部いけそうだな 小さいファイルを頻繁に作ったり消したりしてると対応できないけどね。 なあ
>>781 のような順にディスクを埋めていくような操作こそ
バンド直書きで速くなるんじゃなかったのか？ >>797
バンド直書きはメディアキャッシュに書くより遅くはなることはあっても早くなる事はないよ
バンド直書きの目的はメディアキャッシュの節約だから sataのコマンドセットとかよく知らんが
通常dma転送のバッファなんて1MBくらいじゃね？
一度に数百MBも連続で書く事を宣言出来るようなプロトコルになっとるのかねー？ >>796
対応ってどういう意味だ？
>>795 のルールに基づくなら1つのバンドに書き切れる程小さいファイルなら丸ごと書き込みの
開始かつ終端バンドへの書き込みとなるからメディアキャッシュへの書き込みとなる
2バンドに跨がるファイルの書き込みなら前半は直接バンドに書いて
後半は終端バンドへの書き込みデータになるのでメディアキャッシュへの書き込みとなるだけだけど
ファイルの削除は特に意識する必要はないはず >>799
WRITE DMA EXTで32MiBまで一回で送れる >>799
一応DMAには転送回数なんてパラメータが設定出来るものらしいが
ttps://www.uquest.co.jp/embedded/learning/lecture15-1.html
シーケンシャルライトのサイズがHDD側で認識出来ないと厳しいな いや、別にシーケンシャルライトの終端を含むバンドかどうか不揮発領域に書く前に
揮発メモリで判別すれば良いから揮発メモリにバンド一個分乗る容量さえあれば
シーケンシャルライトの書き込み全体のサイズをHDDがわかってる必要はないか >>801
HDDドライブはPCから送られてきたデータのファイルサイズを知ってるの？ >>802,803
なるほどー 1バンドサイズがどれくらいか知らんけど、
OSのドライバ側で32MBの転送用バッファを確保しておけば
それくらいは行けるわけね。
かなり昔SCSI装置のドライバの改修をやらされた事あるけど、
その時はブロック転送1回64KBくらいだったわｗ(最大512KBと書いてあった気がする)
SATAのコマンド体系とは直接関係ないけど、1回のDMA転送の最大値以下だろうと想像してたんで
シーケンシャルとは言っても、それくらいの単位でLBAアドレスを再受信してるのかなと。
HDD内でメディアキャッシュに書き込みつつメモリにもバッファリングしておけば、
バンド1個分以上の連続になれば、そのままSMR領域に直書きできるね。
バンドのサイズが200MBとかだと、ちょっと実用性が低かもだけど。 数KByte程度のファイルを頻繁に書いたり消したりする使い方しているもんで、OSは削除で歯抜けになったところを埋めるように書き込んでくるから…
SMRだと地獄だろうなぁ。
Xp時代のデフラグは歯抜けや細分化が目で見えて楽しかったな。
今のWindowsのデフラグはつまらん。 ここで必死に会話してる内容をSeagateの現役エンジニアとかが読んだら
失笑するレベルなんだろうな
中の人の一言で全部一瞬にして無に帰しそうな無駄な会話してる気がする >>805
ファイルのサイズは知らないけどシーケンシャルに
どれだけ書き込み依頼が来てるかはわかるので
>>804 で書いたように揮発メモリ使えばファイルサイズ知らなくても
>>795 のルールで書き込みはできるかなと >>807
地獄かどうかは知らんがそういう書き込みはメディアキャッシュ使うだけだけどな
まあ、裏でこそこそ再配置してるのは気持ち悪いとは思うがw >>805
一度OSのファイルシステムの話は忘れてHDDの中の事だけ考えるといいよ。
HDDの書き込みに関しては、
[xxセクタ番地からnnセクタ書込んでくれ]
[xxセクタ番地からnnセクタ書込んでくれ]
・・・
[xxセクタ番地からnnセクタ書込んでくれ]
という感じに連続で送られてくる単純なトランザクションを
いかに効率よく処理するかというシンプルな話でしかない。
ファイルシステムによって、そのxx番地の部分がランダムになる要素も含めて考えたい気持ちもわかるけど、
傍から見ていてこのスレ、話がかみ合ってない要因になってるよ。 >>806
海門のAS0002の場合、バンドのサイズは約30MB。バンド総数は26万個程度。
バンド内のセクターは整列配置だと。
Seagate ST8000AS0002 DM-SMR disk that was recently studied in detail.
With an average band size of 30 MiB, the disk has over 260,000 bands
with sectors statically mapped to the bands, 用語の使い方と視点を明確にして話すだけでもっと改善すると思うんだけどね。 >>813
バンドサイズ平均30MBって事はトラック20本位重ねてるのか！？
結構重ねてるんだな ここ数日言われてるやり方だと、使用率上昇や使い込む＝新品バンド減少に伴って性能劣化する事になりならんか？
30M？単位に汚れバンドが出るって事だし
>>808
俺でもこんなん↑思い付く位だから笑われてるかもね。まぁでも議論は良いことじゃないかな。 >>816
新品バンド減るとなんで性能低下するんだっけ？ >>812
でもまあSMRのせいでいかに効率よく処理するかというシンプルな話
だったのがそうでなくなってきたって話なんだよな >>817
極論、新品バンド0になったら直書きできずここ数日のロジックは破綻ってダケよ？0じゃなくても新品への移動コストが段々上がる…かな？
trimすればマシだろうけど、バンドとFS両方把握してる人は居ないから効率的なガーベージも難しいし。
シミュレーションしないとわかんないけどねー 個人的に不思議なのがosには倫理アドレス触らせといてhdd内部では
物理アドレスで割と好き勝手やってるみたいだけど
そんな事してosとhddで連続の空き領域の認識がズレたりしないもんなのかね
例えば倫理アドレス的に100MB連続で空いてたからそこにosは100MBのファイルを書こうとしたら
HDD内の物理アドレス的には実は100MB連続で空いてるところなんて無くなってて
しょうがないから10MB×10に書いちゃうとか
書き込み速度的にはメディアキャッシュに書くだろうから問題ないだろうけど読み込みがガタガタになるよな
CMRではosからデフラグなんて出来る位だから物理アドレスと倫理アドレスの相違は殆ど無かったんだろうけど >>819
あー、そういう事か。丁度俺が >>820 で書いた疑問だけど
HDD内の物理アドレスとosが知る倫理アドレスがちゃんとリンクしていればその心配は無い
というかその前提で考えてたんだけどな
それこそCMRと同じように倫理アドレスと物理アドレスが紐付いてれば
バンドが新品であろうと無かろうとosに言われた通り上書きしてしまえば良いわけで
というかいずれにしろそうなってないと何も書けない領域が出来てしまうから
物理アドレスで無茶苦茶やってそうに見えて実は俺らが思ってる以上に
物理アドレスと倫理アドレスはちゃんと紐付けてあるんだろうな ちゃんとHDDとosの連続領域の認識を合わせるなら倫理アドレスとバンドを指す物理アドレスを
それこそ順番の入れ替わりなく連続で合わせないといけないけど
なんかそうはならなそうな挙動がSMRにあった気もするが、、、 >>816
海門のSMRはバンド上書きで論理＝物理アドレス。トリム&ガベッジ不要無用。
WD方式は新規バンド別書きで論理 ≠物理アドレス。トリム&ガベッジ必須常用。
SMRが～ と云ってもメーカーが違えば中身は別モノなのよね～ >>823
やっぱそういう事だよね
でもトリムは必須では無いでしょ？
トリム必須だとテレビとかで使えなかったりしそう
トリム無いとそのうち倫理アドレス使った小細工が出来なくなって
メディアキャッシュからの再配置が遅くなるとかそんなとこじゃないか？ >>824
>>735のWDの説明書き(英文)にあるように、TRIM/UNMAPは必要みたいですよ。
OS側からSMRデバイスにどこのバンドがもはや不要であるかを知らせるために。
たぶんファイル削除時のバンドセロ書きクリアというより、論理-物理相対マップの
クリア。ダイナミックマッピングだからこそ。かもですね。 頻繁にファイルの配置換えして、空バンドをできるだけ用意しておく感じか >>825
説明はtrimコマンドをサポートすることでフルスピードでのオペレーションを実行できるとある
ないことによってどれだけパフォーマンスが落ちるか、ないと実行できないとは表記されていないため
必要とはいえない >>827
だよね。
バンドへの書き込み時に空のバンドを用意できなかったら
osが倫理アドレスで書けって言ったところに書いちゃえば良いんだもんな
データの連続性は破綻するけどw
だからメディアキャッシュからの再配置だけじゃなくて
シーケンシャルリードも劣化する可能性があるのか
そこまでしてトリム、再配置の高速化をしなくてはならないのか
逆に心配になってくるな >>823
東芝も更新バンドは別の場所に書くみたい。
技術広報みたいなのに、
メディアキャッシュの更新データとマージして新規バンドに書くみたいなことが書いてあった記憶がある >>820-822 >>828
スッゲー気になるんで一点だけ
倫理（りんり）→論理（ろんり）
つくりは共通してて、侖る（そろえる）
人が目指すべききちっとしたナニカが倫、人倫とか反語の不倫とか
言(ロゴス)が目指すべききちっとしたナニカが論、論文とか反語の暴論とか 上書きする時も、ひとまず新しいブロックにシーケンシャルで書いておいて、
元々の場所は未使用領域にしちゃえばいいわけか。
「SSDが内部でやっていることをHDDでもやろう」って感じだろうけど、
うまくいくのかな。 まぁ、256MBのキャッシュで収まる作業は圧倒的に速くなったよ
64MBキャッシュ 5900rpm CMR から 256MBキャッシュ 5400rpm SMR に変えた後、109MBのメールを自動バックアップした時とか 1TB以上のファイルをちょこちょこ出し入れする場合はSMRは向かないですよね？ >>832
シーケンシャルライトをバンドに直書きする時はその通りで動くだろうけど
そこまでする費用対効果があるのかっていうね
多分新しいブロックに書く効果が大きいのはランダムライトの方なんだろうとけど
そんなに既存のブロックに書くのが遅くなるのかと あー、メディアキャッシュに大量にランダムライトの要求が書かれてた場合に
新規バンドに書き戻す場合は全部シーケンシャルライトで書き戻せるな
もしかしてメリットこれだけか！？
その為にトリムやガベッジを要求してるのか！？ >>834
一応シーケンシャルライトのパフォーマンスはCMRもSMRも変わらないという噂はあるが
osがトリム対応してないとWD形式の場合は死にそうだけど まさにメディアキャッシュから再配置する時に新しいバンドを使う方式が書いてあるな
メリットは書いてないけど
東芝はそうなのか
HDDの大容量化をけん引する瓦記録技術
https://www.toshiba.co.jp/tech/review/2015/08/70_08pdf/a08.pdf WD、256MBキャッシュ搭載のWD Blueシリーズ新6TB HDD. 2019年2月21日 13:59
https://pc.watch.impress.co.jp/docs/news/1170883.html
WD60EZAZ
テックウインド株式会社は、Western Digital製の6TB 3.5インチHDD「WD60EZAZ」を22日より発売する。価格はオープンプライスで、税別店頭予想価格は14,800円前後の見込み。
SATA 6Gbps接続の3.5インチHDDで、WD Blueシリーズの新6TB HDDモデル。256MBキャッシュメモリを搭載し、より高い転送レートと電源効率、静音性を実現。日常のコンピューティングに向けた高い性能と信頼性を提供するとしている。
最大転送速度は180MB/sで、回転数は5,400rpm。Advanced Formatに対応し、ロード/アンロードサイクルは30万回としている。
=====
EZAZってアレですよね？ 8TBを出せって口が酸っぱくなるほど言っているのだが >>840
瓦かどうかのほかに、うっとおしい腕怠惰ことwdidleの存否も確認せにゃならんな よくわからんけど瓦は256MBセクタだと思えばいいの？ >>845
ちょっと違う
瓦に対するランダムライトは手間過ぎて直接書けないから一度瓦ではないディスク領域に書いて
書き込み終了としてHDDが使われてない時にこっそり瓦に書き移してる
だから普通に使ってると割と高スペックに見える
瓦では無いディスク領域、メディアキャッシュが溢れたらとんでもなく遅くなる >>845
あー、セクタで言うなら大体30MB位のバンドと呼ばれる
連続領域として区切られてるみたいよ DRAMキャッシュを1GByteぐらい搭載すれば、メディアキャッシュから書き戻す余裕を確保出来るだろうか？ >>848
結局瓦部分に書く必要があるから変わらんよ
モデルにもよるだろうが何十GBというキャッシュがあふれる話をしてるんだし、DRAMキャッシュが256でも1024でも大差ないだろ >>850
osからの要求に影響の出ないタイミングで
HDDがメディアキャッシュにその場しのぎで書いたosから瓦部分への書き込みを依頼されたデータを
メディアキャッシュ上で既存の瓦部分のデータとマージしてから瓦部分に書く >>848
何故か既存のバンドのデータと書き込みデータのマージを
メディアキャッシュ上でやってるらしいからそれを揮発メモリ上でやれば
メディアキャッシュのハケはマシになる気はするけどね いっきに４TBくらい移したいから瓦はやめたほうがいいんか。
倉庫用途ならそういういっきにTB単位で写すなんてことも多そうやけどね >>848
随分と改善されると思うけど、コンシューマー向けではコスト最優先になので、かなり厳しいよ。
コストかけられる法人なら、ドライブマネージドなドライブを採用するし。
コンシューマーで速度に金を突っ込める人たちはSSDに流れるし。 【速報】WD製SMR6TBがAmazonで販売開始
https://www.amazon.co.jp/dp/B07MYKZGVX/
>キャッシュメモリーが従来の64MBから256MB大幅UP
SMRのことは伏せられているんやな・・・悲劇やな >>851
ありがとう
>>853
領域確保を先にやってしまう※コピーツールでコピーすれば、メディアキャッシュの利用は、
・ファイルの終端部とか
・ディレクトリ情報、
・ジャーナルと
・そのメタ情報
くらいで済むよ
それで足りるかどうかは知らないけど
※OSが持つ機能 >>856
いっそ4TB全領域確保してシーケンシャルに書くコピーツールであれば
メディアキャッシュをほぼ使わずにコピー出来る気もするけどそうはうまくいかないものかね 現行のSMRはシーケンシャルライトはバンドに直書きしてると考えていいのかね
というか直書きしてないとメディアキャッシュが20GBとして50GBのファイルが
事実上書けない位の話になりそうだがそんなSMRが存在するのか？
とはいえ50GBのファイルなんて俺も持ってはいないが ブルーレイのエロ動画とか一本で32GBくるいあるね お前の使い方は普通じゃないぞおじさん「お前の使い方は普通じゃない、普通に使えばSMRでも全く問題ない」 >>863
予防壁ご苦労さん。
そう言えば最近回りくどいな SMRが本当に優れているなら宣伝すれば良い
それをしない時点でお察し 別に優れてはいないでしょ、そんなに悪くないだけで
個人的には書き込み頻度がHDDの故障には無関係って事が大前提なのが受け入れがたいが
グーグルが言ってたとは言うけどねぇ >>866
おそらくGoogleが使っているHDDはCMRだと思うんだけど、それとは機構が異なるSMRドライブに適用しちゃうお前の雑さにびっくりするよ。 根拠は無いけどなんか瓦だからSMRはCMRとは違う機構のはずだって事かな？ >>870
なんか難しい事が書いてあるからSMRはCMRとは違う機構のはずだって事かな？ >>870
制御が違うのはわかるけれど、
書き込み頻度が故障と無関係という論に影響を与える差なの？
そもそも機構というからにはメカニズム的な違いの話でしょ？
ヘッドがSMR用のシールド構造になっていることや
トラックピッチが狭いことによる制度要求の高さくらいしか思い浮かばないんだけど、
それらがグーグル提唱の論を否定する根拠になるってこと？
トラップピッチが狭い製品では故障率が上がってるデータとかあるなら見たいなぁ いや～皆さんの一連のハード及びソフトの考察を見ているとCMRに比べて特にヘッド制御の負担がSMRの方が遙かに大きい
ように思えるんですよ。
GoogleがホストマネージドのSMRしか使っていないならそんなに差が無いかもしれないけど、従来の倍精度でヘッド制御を
するには機械的安定度を保つのに負担が大きいと思っています。 SMR固有の弱点というと、、、
メディアキャッシュ部分の書き込み頻度ばかりやたらと高くて、
その部分の磁性体が劣化しやすいとか？てきとーに言ってみる。 >>876
SMRは基本バンドシーケンシャルな一気書きだからセクタ間のギャップとかも常時一気更新でしょ。
CMRはセクタータッチダウンのセクタ上書き常時でしょ。個体振動とか、ヘッド移動や位置確保の
フォローイングとか。実はCMRの方が微妙のような気がする。使い込んだHDDはトラック代替も多くなるし。 >>877
磁性体劣化によりHDDが故障するのであればそれはCMRでも起こるはずで
グーグルが発表してるはずなんだけどそれが無いからグーグルを信じるなら無いんだろうね >>876
それでどこが壊れるんだ？
どこの負担が増えてるだと言ったほうがわかりやすいか
難しくなったかも知れないがそれを制御するのはコントローラのプログラムじゃないのかと思うけど >>878
メディアキャッシュ部の劣化についても同じことが言えそうな気がする >>878
まあ少なくともグーグルはトラック代替の増加と読み書き頻度は関係性が無いと言ってるんだろうな グーグル曰く温度やアクセス頻度に関係なくCMRは壊れるとのこと
なのでSMRはプラッタへのアクセス頻度が間違いなくCMRより高くなるが
それだけならCMRと故障率は変わらないはず
何か他にCMRには無い故障に繋がる要素が無いと
グーグルの言うHDDの故障率の話
ttp://gigazine.net/news/20070219_disk_failures/ > アクセス頻度に関係なくCMRは壊れる
ないない
そんなこと起きてるなら振動対策が甘い >>882
グーグル論文はHDDの最大の敵は湿度。と云っていたはず。
まーググルのデータセンターなんて恒温槽みたいな空調完備の工場みたいな均質な
環境でHDDぶん回しているわけだからね。個人用途みたいにケーブル蹴飛ばして
4回転半ひねりで見事着地みたいな、アクセス中でもスイッチやらコンセント引っこ抜きの
強制電源断あたりまえ。みたいな世界の出来事じゃないわけで。 >>887
振動じゃなかったかい？
声を当てても速度が落ちる
あと実際は温度は依然として支配的ファクターだった
なぜギガジンが元記事に反した結論で翻訳タイトル決めたか謎
>>887
恒温槽？
グーグルのコンテナサーバなら知ってるが >>888
データセンターを箱物としてみれば恒温槽みたいでしょ。というオチ話ね。わかんないかな。
それと、データセンター的に大敵は湿度。というのはある種の常識みたいよ。↓にはMSの例も。
Humidity, not heat, is a hard drive's biggest threat
https://www.networkworld.com/article/3049428/computers/humidity-not-heat-is-a-hard-drives-biggest-threat.html ググル論文は何年も前のSMRいぜんだtらような。失念。どこかにあるよたぶん。 SMRいぜんだtらような >> SMR以前だったような 振動はトラッキングずれを起こすっていうシーゲートのRVセンサーのPRの動画なら見たことあるけれど。
故障と関係あるんか？ >>892
昔の茂＠バックブレイズでよく壊れたのはサーボが弱いタイプのみ SMRだからってメカ的に変化したわけでもあるまいし 【速報】瓦が現象に認定される
https://egg.5ch.net/test/read.cgi/jisaku/1549621329/517
--------------------------------------------------------------------------
508 名前：Socket774[sage] 投稿日：2019/02/23(土) 13:45:03.86 ID:DBhVM40j
SeaGateの外付けHDDが壊れたっぽい
USB3.0なのに転送速度10MBしか出なくなった。まだ半年なのに
本当に壊れやすいんだなー
517 名前：Socket774[sage] 投稿日：2019/02/23(土) 20:29:53.97 ID:DBhVM40j
HDDツールで調べたところ異常が見られないので、いろいろ試してみた結果
これは瓦という現象のようですね
フォーマットしたらまた毎秒120MB出るようになりました
ありがとうHDDマイスターのみなさん！
情弱には分からなかったよ！
--------------------------------------------------------------------- mdadm -l5 -n6 のマルチボリューム上のext4だと別にどうもならなかったよ
バラけが酷いファイルが連続配置されただけ CPUの新命令のように対応すれば速くなるって代物じゃないし SMR、SMRとぱかにするな、おなじHDDでCMRと何が違う
書き込み方がちょっと違う まあデフラグは元々osが論理アドレス的になるべく連続領域を利用するように
データを並べ直す機能だから終わらないって事はないわな
現実的な時間で終わったのが意外だけど、使用率はあまり高く無かったのかな 1プラッター2TB採用と思われる6TB HDDが出現
http://ascii.jp/elem/000/001/818/1818053/
>販売ショップによると「代理店より1プラッター2TB採用と聞いている」とのこと。
>従来モデルと比べてみると、明らかに「WD60EZAZ-RT」のほうが軽い。
決定的やな・・・悲劇やな SSDですらMLCかTLCかアナウンスされてるのに、SMR隠すのやめーや。クソザコ書き込みで使い物にならねーんだよ >>912
それは2004年ごろの古い文書みたいね。TGMRってトンネリング磁気記録技術とかいう
海門版の垂直磁気記録の解説だったような。トンネリングって江崎玲於奈さんのトンネル
ダイオードを思い出すが違うみたいな似ているのは空気だけのような。
海門の場合はTMCとかいうキャッシング技術を解説した英文ドキュメントにラクダはSMRが
基盤技術だと図示解説されていたはず。AS0002を出した頃は他社にSMRなHDDがほとんど
なかったからブローシャでもSMRって明記していたね。要英文読解毒力。
他社がバンド一括書き込み的SMRなHDDを出すようになってからは止めたようだけど。そりゃ
そうだろう。SMRといっても各社の実装はゼンゼン違うわけで。他社と同じSMRと思われるの嫌。
みたいな。全社そう思っている不文律なのかもねw
明記厨ってまだいるんだね。アハ。 単純にAS002の評判が散々すぎてSMRという言葉にマイナスイメージが付いてるから
SMRという言葉を隠してMTCという言葉に濁してるだけのような気が。
どうせ将来的に多階層な仕組みになるのは確実だし、こりゃいいや的な。 いやいや、SMRがメディアキャッシュ積まないと動かないサイズ以外ポンコツなのは事実なわけで
バレて良いことは何も無いから書かないだけでしょ >>916
そうかなあ。SMRドライブを使いこなすコツは、
①電源投入時間の99%をアイドリングまたは読み出しに用いること。
②デフラグは常に100％維持を心がけること。
この二点を心がければ8TBなら99％埋めるまで常時100MB/s超の読み書きできる。かもね、だよ？
今日はK'sに頑張っていただきたい。 >>917
どういう根拠でそんなコツがあると思ってるのかさっぱりわからん CMRにこだわってる人って今はどのあたりのドライブ買ってるんだろう？
シゲ派だと割高許容してIronwolf？
WD派は青確保しつつ、以降は空気赤？
メーカー拘りない人は東芝？ SSDの場合はどんなにクソスペックでもHDDよりはマシってイメージがあったから
割とスペックはどうでも良かったけど
SMRの場合は既存より劣化するだけでそれより下も代替も無いからな
SSDの時とは大分状況が違うわな >>918
マネさんだったらわかるはず。コスパですよコスパ。
出来て当たり前の院卒君に高給払ってきちんと仕事してもらっても当たり前杉で評価されないが
出来ないとみなされている安給のF君とかを指導した結果きちんとし仕事になれば評価されるでそ。 それにしても今だにSMRの書き込みが遅いと言われるのはよくわからんが
メディアキャッシュに書き込む限りはCMRに劣るはずは無いのだけど
バンドへの直接シーケンシャルライトが遅いのか
メディアキャッシュからバンドへの書き込み中にosから読み書き要求が来た時の
コントロールにSSDのプチフリみたいな穴があるのか >>921
お前はまずメディアキャッシュについてググった方が良い
これがあるからSMRはお前が思ってる挙動になってないと思う >>923
そんなに怖がらなくてもいいのにw
実際にドライブマネージドなSMRで人柱やってみれば、良い点悪い点体感できるから。
エクスプローラで保管庫的ファイル整理するだけなら、メディアキャッシュなんてほとんどスルーだし。
まあ、メディアキャッシュにも大穴ありますよ。ファイル転送1MB/s以下から抜け出せないモードとかね
あのモードにはめ込む条件達成は結構大変。まあ、そういうモードにはめ込まない使い方すればいいだけ。
ま、その辺はマネージャーさんならわかっているはず。 メディアキャッシュをスルーと明言できてしまう根拠が気になる。 >>924
モードって…単にメディアキャッシュが溢れたからメディアキャッシュが空くまで書けなくなってるだけでしょ
悪い事は言わないからメディアキャッシュがどういうものかもう一度ちゃんと調べた方が良いって
人柱にまでなって得た体験が誤った知識で無駄になってる気がするぞ >>924
なー。ともかく1回に書込むファイルは合計２５GB以下。その後はHDDのアクセスランプが落ち着くまで放置！
とってもつかいやすいHDDだよな～SMRって。 シーゲート瓦４TB使ってるけどMediaCacheてランダムライト用じゃないの？
大きいファイルの移動とかで23GBだっけ？超えても速度落ちないけどな
ランダムライトで23GB超えるような使い方はしないから私は気にしないな
23GB以上ランダムライトし続けることって書き込みTEST以外じゃそんなにないと思うけど >>928
もともとSMR部に書き込む速度がCMRより落ちるだろうという予測をしていて、時間稼ぎにメディアキャッシュを使ってるんじゃないの？
と思ってたけど、例えば、CMRのHDDが1ファイル50GB書き終える（アクセスランプも点かなくなる）時間が8分だとして、SMRでも8分で終わる？
というのが気になるところなのです。 >>929
シーケンシャルライトはメディアキャッシュ使わないけど なんかさ
シーゲート日本の多田氏のインプレスでの発言が独り歩きしてるよね
2014年の記事だろってさ >>930
そうですか。ユーザーだとSMRドライブの仕組みまで熟知してるんですねw
時間のあるときに >>929 のような比較してもらうと幸いです。 >>928
一応最近（どの位からは不明だが）シーケンシャルライトは
メディアキャッシュを使わずに直接瓦に書くようにしたって情報をよく見かけたから
始めはシーケンシャルライトも全部メディアキャッシュ経由で書いてたんだろうね >>933
だからさ
ランダムライトで50GBなんてことなら23GB 超えたあたりから激遅くなるだけだよ
それ以外は変わらない
写真とか小さなのファイルを万単位で書き込むような特殊なことしないなら気にすることないって >>929
落ちるどころか特に瓦へのランダムライトは遅すぎて使い物にならないから
メディアキャッシュを用意したって所だよ
単純に書き込み量が数倍はくだらないだろうからね
現実には数10か数100倍位になってるみたいだけど
他の人も言ってるように数10MB以上のシーケンシャルライトはメディアキャッシュ使わずに
直接瓦に書くようになってるみたいだからそれ未満の書き込みでメディアキャッシュが溢れる
20GB以上の連続書き込み量になると真の瓦への書き込み性能が見えるだろうね >>935
自分の用途だと毎週、TrueImageのシステムバックアップ先、地デジとBSを録画したファイルを保存するところなので
軽く23GBを超える訳ですよ。ファイル数は二桁程度です。
現状ならば、それぞれのバックアップを全て済ませても今使っている8TBのIronWｏｌｆならば30～40分程度で終わりますが、
終了するまでに8時間とか24時間になると大変使い勝手が悪くなるので困るなーって思います。 大量のデータ（残量用少し）が書き込まれたSMR-HDDの各ファイルに対して
ほとんどのブロックを書き直す必要のあるような複数ファイル内容の書き換え（1bitだけの書き換えとか）
を連続して実行すると見かけ上は即座に書き込みが終了するけど
SMR領域への書き戻しは数時間とか数十時間かかるんだろうなあ
書き戻しが終わらないうちにこういった操作を繰り返すとメディアキャッシュを食いつぶすことになる？ >>937
だから写真みたいな小さなファイルって言ってるでしょ
地デジ、BSの録画はGB級でしょう
ランダムライト、シーケンシャルライト、SMRでググってみたほうが良い
何回も同じ説明するのは疲れるぞ >>808
> ここで必死に会話してる内容をSeagateの現役エンジニアとかが読んだら
> 失笑するレベルなんだろうな
> 中の人の一言で全部一瞬にして無に帰しそうな無駄な会話してる気がする
まあ、そうですねw >>932
記事に限らずAS002の悪評を引きずってるっていうのはユーザーにもあるだろうね。
でもBarracudaの世代になって完全に解消したわけでもないだろうし、
どこまで改善されてるのかっていう点では疑問に思う人が居てもおかしくないだろう。
本当に改善されてて問題ないのなら堂々とSMRを名乗ればいいのに
それをしない時点で疑われても仕方がない。 >>937
100MB以上のシーケンシャルライトだったらメディアキャッシュを使わずに
直接瓦に書かれるだろうから大丈夫だろうけどね
とはいえ仕様として公開されてないから保証は無いけど >>941
悪評以前にメーカー自らSMRはアーカイブにしか使えないCMRの劣化版だって宣伝してたもんな
それを今更普通に使えるようになったとか言われてもね >>940
お前はなんでそう物事を考えない方向に逃げるんだw
少しはSMRがどういう仕組みで動いてるか考えてみってw
>>839 の東芝の書いたpdf読むだけでも大分理解出来ると思うぞ >>943
「普通」を定義するための何度目かの大戦争が起こってしまう…
年間55TB、週におよそ1TBの書き込みをするかどうかでざっくり判断なされい >>946
>>385-386 は俺がリストしたのだが、中でも↓は精読に値する。
このスレでみ何度もここから引用させてもらっているしね、ググった日本語情報とは
別の情報がたくさんあるよ。リストの他も併せて読んでね。東芝のアレは今的に古過ぎだし。
↓このレベルのPDFをキチンと読めたら、キミも少しは知識が増すかもしれないね。
Evolving Ext4 for Shingled Disks
https://www.usenix.org/system/files/conference/fast17/fast17-aghayev.pdf >>947
色々調べたけど別に録画でも問題なさそうだったわさんくす >>948
その論文をちゃんと読んだほうがいい
少なくともそれを読んで運用（使い方）でカバーできるからSMRでも問題ないっていう話にはならないと思うが >>949
CMRだと、ほぼ大丈夫だったことが、SMRだとそこそこ大丈夫に変化するので、
録画なんて出来てなくても気にしないって用途ぐらいでないと厳しいかもよ。 >>951
そうなん？
PT3スレでも使ってる人いたけど問題ないっていってたけどなぁ >>948
まじで！？なんでSMRのパフォーマンス維持にデフラグが有用なんだ？ >>948
> 電源投入時間の99%をアイドリングまたは読み出しに用いること。
これの言ってる意味がわからんのだが、HDD起動してから放置しろってこと？ >>952
別に大丈夫だと思うよ
逆にパフォーマンスが怪しいのに信頼性まで失ったのでは目も当てられん気がするし >>950
> >>948
> その論文をちゃんと読んだほうがいい
> 少なくともそれを読んで運用（使い方）でカバーできるからSMRでも問題ないっていう話にはならないと思うが
論文はろんぶんであって、保険の勧誘案内書じゃないの。学校で読み方ならわなかった？ >>953
他に為すべきはあんまりないから。
エクスプローラでセルフなファイルコピーするだけでもデフラグ効果がある。
2GBファイルで断片がすう万コ超とか酷いファイルを普通にコピーすると>>896みたいに
10MB/s程度に遅くなることはある。その程度の生温さで済むのがファイル断片効果。
ただしそういう酷い断片だらけのファイル生成を続ければ、あの超低速もーど
はめ込むことができる。100KB以下のセクタ書きをずーと続けることになるからね。
そんな状況でアイドル時間が与えられなければMCはオーバーフローし易くなる。
MCオーバーフロー後の茂SMRの最悪もーどでは俺的には500KB/s 例の資料PDFの図版では
10KB/s位まで落ちるみたいね。それでもゼロにはならない。細々とユーザリクエストに応え続ける律儀さはある。 断片が無いファイルならコピーとかしても100MB/sは普通に出るみたいね俺環のAS0002でも。
>>954
えろ)どうがとかを100本異常連続DLしなさんなということ。
ネットフル速DLするなら休み休みでどうぞ。CMのフラッシュクリアは
そのお休み中になされるからね。お休み時間は数分以上を推奨。 問題あるにしろ無いにしろ、対策の内容も含めて
その人の環境でっていう条件が付くのがSMRって感じがするわ
CMR程度に無条件で人に薦められるようにはならないんだろうな。
録画にしてもどう書き出すかによって適・不適が有るように思えるし。 SSDのプチフリと同じ様にうまくコントロールさえ出来れば問題無く使えるようにはなるとは思うけど
というかまだなってないのかどうか知らんけど 今更ながら >>4 見る限り微妙にSMR遅いのな
この微妙な遅さはなんだろな >>961
面白いテストデータですね。特にtest 1が面白い。
書き込み時間 CMR：6分59秒(419秒) SMR:5分26秒(326秒) テストデータサイズ 45.5GB
このテストの着目点はデータサイズとファイル転送時の推移グラフ。
45.5GBはメディアキャッシュの想定サイズ25GBの約2倍。そういう大きなファイルをコピー
したにもかかわらず、ファイル転送速度は一定水平。このコピー試行ではSMRドライブは
メディアキャッシュ経由の書き込みはせずにSMR直書きしていた。と推定できる。そして
この試行でSMR直書きのシーケンシャルライトはCMR対比で約1.28倍高速であった。
海門8TBのラクダは大きなファイルのシーケンシャルライトはメディアキャッシュを用いず
直書き。かつCMRより高速。と思い込むことが可能なネタになっていますね。
SMR（瓦記録）のHDDは本当に遅いのか試してみた
https://ameblo.jp/iso5210/entry-12426001030.html >>961
> この微妙な遅さはなんだろな
テスト2-4は複数ファイルの一括コピー。特にテスト4はファイルサイズが小さいので
メディアキャッシュ経由のコピーみたいですね。コピーの推移グラフもノコギリ状。
メディアキャッシュ上のデータをSMRバンドに書き戻す時はホストにビジー通知して
コピーデータの受け入れを停止遅延させ、とりあえずのフラッシュ終了で受け入れ再開
というサイクルを繰り返すので、転送速度がノコギリ状のグラフになるみたいですよ。
グラフの濃い緑の最大値が中央を超えていないでほぼセンターなのはメディアキャッシュに
余裕がある状態。メディアキャッシュがオーバーフロー状態になるとグラフのほとんどが
濃い緑一色。ほぼ100%ビジーになりますです。
テスト1：BD-R DLデータを想定した約45GB、1個のファイル
テスト2：動画データを想定した約25MB～150MB、252個のファイル（合計20.5GB）
テスト3：画像データを想定した約500KB～1.5MB、500個のファイル（合計398MB）
テスト4：極小データを想定した約1KB～4KB、20,730個のファイル（合計26.2MB） メモリやM2をキャッシュ代わりにしてHDD高速化を計る技術があるけど
あれ使ったらSMRの書き込み低下は起こらない？ >>964
>>グラフの濃い緑の最大値が中央を超えていないでほぼセンターなのはメディアキャッシュに
>>余裕がある状態。メディアキャッシュがオーバーフロー状態になるとグラフのほとんどが
>>濃い緑一色。ほぼ100%ビジーになりますです。
これは勘違いの間違い。スマソ。例のグラフはエクスプローラのコピー速度の推移で
上記説明はコピー時のパフォーマンスモニタのドライブビジー状態の推移経過の観察。
SMRのHDDの状態観察を行う場合はパフォーマンスモニタで当該ドライブのビジー状態を
チェックすると面白いです。 >>965
平均３０MBのSMRバンド2000本分の容量６TBのSMRドライブがあったとして、
そのSMRバンド2000本それぞれに4KBだけの残量が分散しているとしてその総残量8MBを埋めるファイルの書き込みには、
2000本すべてのSMRバンドの書き換え、すなわちSMRドライブ６ＴＢ分すべての読み出し書き換えが必要なんだぜ > 平均３０MBのSMRバンド2000本分の容量６TBのSMRドライブがあったとして
60GB？
HDDのアクセスは普通LBA番号指定でしょ。まあ、実際にそういうファイル書き込みを行う
ソフトがあるならば、実測レポートして下さいな。 >>964
バンドに書くときにホストビジーってまじで！？それやっちゃ駄目でしょ
って確かにそれが妥当にも思えるけど
でもそんな一瞬だけバンドに書く時間与えられても何も書けなくね？
コントロールミスじゃあないのか？ >>965
そもそもSMRにCMRより金を書けたら本末転倒になるっていうメーカーの暗黙の制限もあったりな >>969
周辺機器のアクセスにはハンドシェークという概念の実装があるんですよ。
HDDならAHCIとかね。HDDのドライバがそのハンドシェークを担っているの。
普通のユーザはそんなこと気にする必要もないいけど、ドライバーを書く
システムプログラミングでは、そうしたホストと機器間のハンドシェイクを
ある種の規約仕様に従って綿密に構成しなくちゃならない。ドライバーの
プログラミングは面白いいですよ。若い人向けだけどね。 >>971
SMRがメディアキャッシュからバンドにコピーする時に外部にビジー通知するかどうかって
どれだけSMRが外部に迷惑かけずに内部処理を出来るかだから
あんまドライバとか関係なくね？ ドライブマネージドとホストマネージドの区別くらい付けようぜいい加減 10～15MBのファイルを数千個、50GB分コピーしたらどうなるんかね >>972
Windows10に限らずcドライブ使用率100%はフリーズ現象の直結原因。そんな現象と対処法
に関するページはググればすごく多い事が判る。↓はほんの一例。
SMR HDDをCドライブ使用しメディアキャッシュをオーバーフローさせたら確実にPCはフリーズ
状態に陥るだろうね。ドライブ状態が100%ビジーであることを知ることができるのは、
HDDがビジーであることがホストの問い合わせに返事として知らされるからなのよ、
君忙しい？ うん忙しい。とHDDが返してきたらどうするか。それはアプリ次第だろうねえ。
特殊な対応をアプリが取らなかったら処理途中のデータは失われて、アプリはフリーズしちゃうだろうね。
ドライブ使用率100%でフリーズという現象への対処法ページ
https://www.partitionwizard.jp/partitionmagic/100-disk-usage-windows-10.html
https://ikasenmo-answer.com/windows10-disk-100/
http://akisyo.com/2018/11/21/windows10でディスクの使用率が100％になる/
タスクマネージャー
https://ja.m.wikipedia.org/wiki/Windows_タスク_マネージャー
https://pc-karuma.net/windows-10-task-taskmanager/ >>965
RAMキャッシュをインスコしても事態はさほど変わらないと思うな。
キャッシュは所詮FIFOで順繰り処理の待ち行列を大きくして
コピーソースの読み出し時間を稼ぐだけの努力だから。
それより、極小ファイルの大量シーケンシャルライトをメディアキャッシュ経由に
しない方法はあると思う。コピー前にファイルデータをISOファイルみたいな
アーカイブにまとめて連続した空きエリアに一気書きした後、ディレクトリ情報を
まとめて一括更新。これならCMRでもSMRでもファイルコピーは高速化できるはず。 新手の拷問に使える
「白状しなければお前のPCのCドライブをSSDからHDDに換装してやるぞ」
「そんな脅しに屈すると思うのかw」
「このSMRのドライブにな」
「それだけは勘弁して(泣」 しかし今の安PCにはSMRのHDDがどんどん採用されてるのに、どうするんだろうな
容量に空きがあるから適当にファイルぶっ込むか、とやるとすぐにビジーになってしまう
Windowsが悪いでごまかすだけかな >>978
ワロタw
今や起動ドライブはSSDの時代でしょ。1TBでさえ１万円台前半に落ちつつあるのだし。
ちょっと前にfirecudaの2TBに換装したのだが直前直近に起動したアプリだけがSSD風に
高速起動するだけであとは普通のSMR。がっかりしたですよ。尼で3200円程度で安売り
されてた240のSSDに切り替えたら目鱗。
今でも継続しているかもな、みかか&OCNの5000円クーポンが手に入ったので240GBのSSDを
３個ポチりましたよ。バックアップを考慮して断捨離進行で240GB。
1TB以下のHDDは全てオク処分予定。チラ裏でスマソ。
https://point.goo.ne.jp/j/ssc/staticContents/show/cp_173 >>976
これってWindows10のバグじゃないの？CMRでも起きてるんだろ？
SMR関係なくね？ Windows10のディスクアクセス100%でフリーズ問題 [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/win/1482496224/ >>974
Dropboxに採用されてるし
去年末に15TBが発表されてた >>977
その空きエリアに一気書きの工程がメディアキャッシュに書いてる事と同じ事じゃね？ シーゲートの方式だと
一気に書けてもバンドサイズの単位だし、こぼれた分はメディアキャッシュ行きでしょ？
指示のあった書き込み開始セクターとバンドの最初のセクターが一致するわけでもないから、
一連の書き込み指示の最初と最後は一気書きからこぼれると見るのが妥当じゃね？ >>986
まぁそうだろうね。
そう思うから、空き容量や使い込み具合による低下を恐れるし、ソレを想定しないベンチ・レビューや問題ない・問題なかった報告を見ると生暖かい目で見てしまう。 ファイルシステムが違えば色々と変わってきそうだけどな
ここにいる人たちはNTFS前提で話してるのか知らんけど >>986
妥当だと思うけどだからどうした？
別にそれがシーケンシャルライトのパフォーマンス低下要因とにはならんと思うが SMRのHDDとQLCのSSDはノストラダムスが予言した恐怖の大王 2.5インチはほとんど瓦
……え？ 2.5ならSSDが当たり前だろって？ テレビ録画用に2.5インチは普通に選ばれるけど、長期保存用にSSDはないわ 〃´⌒ヽ
., -―― ﾒ／_´⌒ヽ
／ ／￣ ´ヽ ヽ
./ , /// ﾄ. ! ､ 丶ヽ
l / /（(（リ从 ﾘﾉ）） '
| i l ． ヽﾉ ．V l
l ,=! l /// ///l l ねんがんの１４ＴＢをてにいれたぞ！
l ヾ! ', l ヽ_フ l l
| ヽヽヽ //
l ヾ≧ , ＿_ , イ〃
li （´｀)l {ﾆ0ﾆ}､ |＿"＿＿＿
li /l, l└ ﾀl」／| ＨＤＤ |
ﾘヽ/ l l__ .／ |＿＿＿＿＿|
,/ L__[]っ ／ ( ⌒ ) ／
::::::::/ ヽ、 :: ::: ::: :::::::::::::::::::::::::::::::::
:::::/ lﾊ ::: : :: :::::::::: :::::::::::::::::::::::::::::
::::l l /ﾉﾘ ::: : :: ::::::::::: ::::::::::::::::::::::::
:::| /） / ::: : :: ::::::::: :::::::::::::::::::::::::::::
::l /ｲ/| . :. :. .:: : :: :: :::::::: : ::::::::::::::::
/ / ||/ /￣￣￣￣￣７l:::::::::::::::::::
i /_,／i! /⌒⌒⌒⌒⌒/ ,l::::::::::::::::
l 人 /⌒⌒⌒⌒⌒/ /::::::::::::::::
l / /⌒ヽ⌒⌒⌒⌒⌒/ /::::::::::::::::
l /iｌ | ） ⌒⌒⌒⌒/ ./::::::::::::::::
ll l i! ｀ｰ、＼＿＿＿_ / ｎ/::::::::::::::::
lヽ l |＼. ＼ /⌒〉:::::::::::::::: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 21時間 8分 6秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
