【瓦記録】SMRのHDD 6台目【ﾌﾟﾗｯﾀ枚数減】
1Socket774 [sage]
AAS
993Socket774 [sage]
994Socket774 [sage]
995Socket774 [sage]
996Socket774 [sage]
997Socket774 [sage]
998Socket774 [sage]
999Socket774 [sage]
1000Socket774 [sage]
10011001
1002過去ログ ★
AAS
!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 5台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1551107096/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
!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 5台目【ﾌﾟﾗｯﾀ枚数減】
https://egg.5ch.net/test/read.cgi/jisaku/1551107096/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
2019/04/04(木)00:02:43.36(GOKy0VfU0.net)
993Socket774 [sage]
>>992
5万秒のうち1万秒は20％。4万秒が既に大変ってのはyesですが20％は結構な量→200Mで書けるHDDの期待値が160Mになる
解析してるかどうかは判らないし俺様理論である事には変わりませんが「大した事無い！やってる訳無い！」ってのは乱暴と思うよ。
まぁコスト(bugコスト含む)の面でヤってないと私個人は思いますがw
5万秒のうち1万秒は20％。4万秒が既に大変ってのはyesですが20％は結構な量→200Mで書けるHDDの期待値が160Mになる
解析してるかどうかは判らないし俺様理論である事には変わりませんが「大した事無い！やってる訳無い！」ってのは乱暴と思うよ。
まぁコスト(bugコスト含む)の面でヤってないと私個人は思いますがw
2019/07/02(火)08:18:38.14(Snmjx7Gd0.net)
994Socket774 [sage]
2019/07/02(火)08:42:38.28(khR3/b64d.net)
995Socket774 [sage]
2019/07/02(火)09:49:11.87(XSCJb4TVd.net)
996Socket774 [sage]
>>992
なんとなくヤバそうなんてレベルじゃないんだよ。
１万秒は計算したのか？ ３時間近いんだぞ？
じゃあ、ファイル本体は４万回で４万秒で１１時間かかるのか？ おかしいだろ？
お前は答を直接書いても頭に入らないようなので自分で考えてみろ。
落ち着いて考えればどこで間違えたかわかるはずだ。
やっぱり（少なくとも今の）お前は相手の間違いを見つけてやろうということに必死で、
肝心なことに頭がまわってないように思えるな。
フォーマット時に不適切な挙動が発生する可能性に気付きそればっか考えてるんだろう。
＞しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。
＞「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
＞そもそも、予測が当たれば効率が上がるというだけで、
＞外したところで大きな問題になるわけでもない。
と説明したのに、「理解できず明確な理由をもっておかしいと指摘できるわけでもないのに」
「致命的な欠陥HDDが作り上げられてる」とか妄想して攻撃できてるつもりになってるわけだ。
なんとなくヤバそうなんてレベルじゃないんだよ。
１万秒は計算したのか？ ３時間近いんだぞ？
じゃあ、ファイル本体は４万回で４万秒で１１時間かかるのか？ おかしいだろ？
お前は答を直接書いても頭に入らないようなので自分で考えてみろ。
落ち着いて考えればどこで間違えたかわかるはずだ。
やっぱり（少なくとも今の）お前は相手の間違いを見つけてやろうということに必死で、
肝心なことに頭がまわってないように思えるな。
フォーマット時に不適切な挙動が発生する可能性に気付きそればっか考えてるんだろう。
＞しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。
＞「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
＞そもそも、予測が当たれば効率が上がるというだけで、
＞外したところで大きな問題になるわけでもない。
と説明したのに、「理解できず明確な理由をもっておかしいと指摘できるわけでもないのに」
「致命的な欠陥HDDが作り上げられてる」とか妄想して攻撃できてるつもりになってるわけだ。
2019/07/02(火)10:07:22.22(U4gz3FWT0.net)
997Socket774 [sage]
>>993
あなたも考えてみてね。
「ファイル総サイズ392,336,035バイト」書き込むのに１４時間かかってどうするの？
バグの心配をするなら、一番古いものから処理するだけでいいんじゃないかな。
単純だがこれもアクセス解析の一種。結果的にアクセスパターンを追ってることになるからね。
これだけでも単なるコピー程度なら無駄書き換えは大分減らせると思うし、
彼が気にしてる問題もすぐに解消するので欠陥とか言わせないｗ
あなたも考えてみてね。
「ファイル総サイズ392,336,035バイト」書き込むのに１４時間かかってどうするの？
バグの心配をするなら、一番古いものから処理するだけでいいんじゃないかな。
単純だがこれもアクセス解析の一種。結果的にアクセスパターンを追ってることになるからね。
これだけでも単なるコピー程度なら無駄書き換えは大分減らせると思うし、
彼が気にしてる問題もすぐに解消するので欠陥とか言わせないｗ
2019/07/02(火)10:08:13.16(U4gz3FWT0.net)
998Socket774 [sage]
>>992
あ、念のためだが、お前がその記事を持ち出してきたのでそれに付き合っただけで、
メディアキャッシュに丸々入り切るサイズなのだからとくに工夫する必要もない。
全部溜めてから吐き出せば理想的な書き込みができるとか馬鹿なことを考えるなよ？
最終的には、溢れる可能性がある規模のケースに置き換えて考えないと意味ないからな。
念のためだが「この記事を持ち出したのはそっちだ」とかいうおかしな反応が予想されるので、
管理情報をある程度まとめ書きしていることの根拠として出しただけだと先手を打っておく。
流石にないかｗ
あ、念のためだが、お前がその記事を持ち出してきたのでそれに付き合っただけで、
メディアキャッシュに丸々入り切るサイズなのだからとくに工夫する必要もない。
全部溜めてから吐き出せば理想的な書き込みができるとか馬鹿なことを考えるなよ？
最終的には、溢れる可能性がある規模のケースに置き換えて考えないと意味ないからな。
念のためだが「この記事を持ち出したのはそっちだ」とかいうおかしな反応が予想されるので、
管理情報をある程度まとめ書きしていることの根拠として出しただけだと先手を打っておく。
流石にないかｗ
2019/07/02(火)10:13:26.59(U4gz3FWT0.net)
999Socket774 [sage]
2019/07/02(火)12:19:07.79(khR3/b64d.net)
1000Socket774 [sage]
>>996
まあ普通に考えたら5万秒、4万秒共にアウトか共にセーフかどちらかで
前者ならアクセス解析ではなく別の対策をするべきじゃないかと
アクセス解析では5万秒を4万秒にする事しか出来ないでしょ？
5万秒はアウトで4万秒はセーフだからアクセス解析でなんとかすべき
なんて方がアクセス解析したい人の都合の良いサンプルの抜き出しじゃないかとね
10万秒と8万秒でも同じ事
結局20%しか向上は認められないわけだし
MCのサイズを調整した方がお手軽で現実的ではないかと
まあ普通に考えたら5万秒、4万秒共にアウトか共にセーフかどちらかで
前者ならアクセス解析ではなく別の対策をするべきじゃないかと
アクセス解析では5万秒を4万秒にする事しか出来ないでしょ？
5万秒はアウトで4万秒はセーフだからアクセス解析でなんとかすべき
なんて方がアクセス解析したい人の都合の良いサンプルの抜き出しじゃないかとね
10万秒と8万秒でも同じ事
結局20%しか向上は認められないわけだし
MCのサイズを調整した方がお手軽で現実的ではないかと
2019/07/02(火)15:48:49.81(khR3/b64d.net)
10011001
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 89日 15時間 46分 6秒
新しいスレッドを立ててください。
life time: 89日 15時間 46分 6秒
Over1000Thread.net)
1002過去ログ ★
■ このスレッドは過去ログ倉庫に格納されています
[過去ログ]