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

1 ：Socket774 ：2019/04/04(木) 00:02:43.36 ID:GOKy0VfU0.net

!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

952 ：Socket774 ：2019/06/30(日) 09:45:18.17 ID:/58ZRlBL0.net

長期保存は石に刻むのが一番だろ

953 ：Socket774 ：2019/06/30(日) 11:37:41.90 ID:sTw1jGEi0.net

なんか、すごいよな。自分の理論構築によればSMRが遅いとかありえないって感じで。
むしろ、OSと使用者の問題に尽きるのでSMRを推進していきたい！とかで。

954 ：Socket774 ：2019/06/30(日) 11:52:26.09 ID:vbg/dU/G0.net

>>945
茂の場合は
osに公開している論理アドレス=瓦領域の物理アドレス
で瓦書きが必要な書き込みデータは一旦論理アドレスと共にMCに書いて
後で瓦領域の本来の書き込み先に非同期に瓦書きするって事でしょ
アドレスから先の内容を書き換えるってのはこの瓦書きの話
書き換えるではなく再書き込みだけど
で、最終的に書き込まれる先はosの指定した通りのアドレスになるから
アドレス変換されるとは言い難いかなと

955 ：Socket774 ：2019/06/30(日) 12:31:03.14 ID:vbg/dU/G0.net

>>949
MCことメディアキャッシュは不揮発領域に確保されてるキャッシュ
一台のSMR内の最外周に20GB程確保されてると言われてて
使用目的は時間のかかる瓦領域への瓦書きを後回しにすること
なのでそもそもSMRはホストが暇じゃないと成り立たず
暇が無いと >>238 のようにMCがいっぱいとなり
ホストからの書き込みがMCから瓦領域への瓦書きによりMCが空くまでまたされる事になって
とんでもない遅さになる

956 ：Socket774 ：2019/06/30(日) 12:49:30.51 ID:dh+NuBbK0.net

実際の書き戻しに要する時間とかそのタイミングとかって判明してないんでしょ？

以前に出てくるSMRの不具合報告と、最近の報告を考えると
以前は書き戻しはアイドルタイムにするようにしてたけど、
最近は定期的に割り込ませてるんじゃないかという気はする。

ファームでチューニングできる分野だし、
ひとまとめに書き戻し=激遅状態ってのはどうだろうね

957 ：Socket774 ：2019/06/30(日) 14:03:45.39 ID:aPjClehR0.net

>>938
絡まれた場合でも、スルーすると
相手の反論を受け入れたと取られてもしかたがないのがやっかいだけどね。
本人はともかく外野にもそう判断されかねない。
まあ、真面目に付き合っても埒が明かないレベルはどうしようもないけど、
こういうのがいるとスレの情報価値が一気に下がるんだろうなあ。

958 ：Socket774 ：2019/06/30(日) 14:10:33.85 ID:UpMBc+KYd.net

>>956
以前ってのがいつだかわからんけど >>9 を見る限りホストの書き込み処理中でも
MCからの瓦書きはやってるのだろうね
というか完全なアイドル中なんてのが来る保証も無いから
何れにせよある程度ホストの処理に被ってもにやらざる負えないだろうと思う
とはいえ激遅にならないためにMCがあるんだからMCに空きがあるのに激遅になるような
チューニングにする程メーカーはアホでは無いと思うけど

959 ：Socket774 ：2019/06/30(日) 14:12:49.52 ID:Byj7xik90.net

価値もなにもここは隔離スレだよw
延々と長文書いても結論なんか何一つ出ないんだから
他所でやると嵐認定されるわ

960 ：Socket774 ：2019/06/30(日) 14:21:09.45 ID:aPjClehR0.net

ﾜｯﾁｮｲ fe11-Eaty さんは中々考察できる人みたいだけど、いかんせん知識不足。
このスレだけでも読んでみると色々面白いと思うよ。

>>917
連続 LBA アクセスを検出して直接瓦書きすることもあるよ。

>>949
前段。根本的に SMR とはそういうもの。多かれ少なかれ暇な時間を必要とする。
最悪時に破綻するのはさけられない運命の中、
なるべくユーザに遅くなったと感じさせないよう工夫したり、
破綻するのは仕方ないものとしてそれまでのパフォーマンスを優先する等、
様々な方針が考えられる。

後段。ホスト側で制御する方式はすでにある。
製品としても少なくともサンプル出荷はされているが実働しているかは不明。
一般レベルでは MS に動きがない限り普及することはないでしょう。

961 ：Socket774 ：2019/06/30(日) 14:22:05.28 ID:aPjClehR0.net

>>912
ちょい高度な話になるので、できれば SMR を理解してから読み直して。

アドレス変換なしもしくはバンド（瓦最小単位のこと）単位変換方式では
メディアキャッシュのバンド単位管理はありえると思う。
有効セクタが少なくすかすかになりがちなのが難だが逆に言えば吐き出しが容易。
かき集める手間もなく状況によって作業時間が大きく変わることもない。

ただ、瓦の書き換えは本当に大変な作業なので
（一説にはバンドひとつあたり数秒、理論上最短でも一秒弱はかかる計算）、
管理情報のように頻繁に書き換えられるものは
なるべくメディアキャッシュにキープし続ける戦略も考えられ、
この場合セクタ単位でぎっしり管理したほうが沢山キープできるので
どちらがいいかは微妙なところ。

962 ：Socket774 ：2019/06/30(日) 14:23:34.44 ID:aPjClehR0.net

>>956
その人は何度説明しても >>342 から一歩も前進しないので言うだけ無駄。
RAID コントローラから切り離されてしまうリスクとかまったく理解できないみたい。

963 ：Socket774 ：2019/06/30(日) 14:34:52.24 ID:aPjClehR0.net

>>959
もちろん隔離スレだと思ってるｗ
他者の考えを知り各々の中にある正解が変化する。
それだけで十分意味があるんだよ。
大多数が納得すればスレとしての結論にはなるかもしれない。

964 ：Socket774 ：2019/06/30(日) 14:44:28.75 ID:/iaOAPFq0.net

前スレで言われてたこれ発動するしかないわ。
https://egg.5ch.net/test/read.cgi/jisaku/1551107096/654

965 ：Socket774 ：2019/06/30(日) 14:47:46.83 ID:/iaOAPFq0.net

で、妄想スレの住人は、本スレに一切書き込みを行わないこと。

たとえ一般的な話をしようとも、お前ら絶対に推測持ち出して争いになるから
自重しろ。お願いとか言わんぞ。もう堪忍袋の尾は切れてる。

966 ：Socket774 ：2019/06/30(日) 15:24:49.84 ID:Byj7xik90.net

>>965
タイミング的には丁度良いな
特に反対する理由もないし分ければ良いよね、維持できるかは知らんけど

967 ：Socket774 ：2019/06/30(日) 15:39:29.09 ID:/iaOAPFq0.net

本スレが過疎って、推測スレが賑わって世間的にも
有用な情報構築ができればそれで良いと思ってる
俺は荒らしたり攻撃したいわけじゃない

重要なのは、目的が違う相手が考えを押し付けられたり
エビデンスの取れてない推測情報でスレを溢れ返らせて
実用情報を欲してる人が迷惑している状況を改善したい

968 ：Socket774 ：2019/06/30(日) 15:41:35.57 ID:/iaOAPFq0.net

このスレにはスレタイをもとにいろんな人が来ていると思う
SMRの実用的運用情報が欲しい人に対して、SMRの技術に
関心があってとことん知識欲を満たして語り合いたい人が
ちょっと「やり過ぎてる」ことを自覚してないのが問題なんよ


電車でいえば運行情報を知りたい人に鉄オタが喧嘩売ってる状態

A「なんかこないだ乗った特急電車、乗車率120%超えたら、
A駅で乗り換えのはずが通過して、何のアナウンスもなく
各駅停車になったんだけどありえない」
B「新型車両はそうなるらしい。でも何の掲示もアナウンスも
されてなくてみんな困ってる」
異常者「A駅で乗り換えるとかw そんなの普通の乗り方じゃないし。
120%の乗車率とかも異常。120%の乗車率になるとかありえない」
A「えっ」
B「えっ」

A「どうしたら目的地に予定通りつけるか教えて」
B「現状識別無理だから、別の公共交通機関を検討しないと…」
異常者「いやいや、普通に乗れよ。おれこないだ乗った※1けど
大丈夫だったし、ありえんわ。 おかしいって言うなら、乗車率
みたいなアバウトな指標とか120%とか起こりえない指標じゃなく
現実的に正確な条件提示してよ。そんなことより新しい機種は
〇〇方式のブレーキを搭載してるから、速度が落ちすぎないよう…」
A「なんやねんこいつ」
B「なんやねんこいつ」

969 ：Socket774 ：2019/06/30(日) 15:49:39.70 ID:vbg/dU/G0.net

>>967
気になるのはその目的っていうのは具体的にはなんだろなと
例えば「テレビ録画用にSMR買って大丈夫？」って質問はどっちのスレに書くべきか？
本スレではエビデンスを揃えて答えないといけないから
本スレに書かれてエビデンスが揃えられればそのまま本スレで答えられて
そうでなければ推測スレに誘導されるって流れかね

970 ：Socket774 ：2019/06/30(日) 16:14:44.25 ID:fQEDJFiP0.net

無粋だなあ
パズルを解くように中身のつくりについて色々と想像するのは楽しいじゃん

971 ：Socket774 ：2019/06/30(日) 16:16:47.86 ID:/iaOAPFq0.net

>>964は引用しただけでもまさにこの通りのスレタイにしようというほど
厳密な提案ではないです(´･ω･`)
「推測」という縛りもどうかと思ってきたし、難しいね

スレタイの文言は別として、各スレの目的はこんな感じはどうだろう

実運用スレ：使い道、使い方、一般知識
・SMRのHDDの使い方、実際の挙動報告とか、所有者によるアドバイス
　目的別実製品の推奨／非推奨のアドバイス
※使い方に関する推測を含む意見は許容する

仕様スレ：技術仕様メイン
・技術的な『仕様』を解明するスレ
　仕様に関する推測妄想未来予測大歓迎で語り合おう

972 ：Socket774 ：2019/06/30(日) 16:22:39.01 ID:/iaOAPFq0.net

>>970
それはいいけど、技術仕様論ずる奴らの中の一部の人が
実運用の中で困った人の作業内容を極端な使い方だとか
そんな作業するの一回だけでしょとかレッテルを貼って
否定したりするのを繰り返してきたのが問題なんだよね
だからスレを分ける意見を出した

みんなが要らないというならそれで良いけど、分けないなら
SMR盲目的推進派も絶対否定派も、理論大好きっ子も
みんな仲良くやっていって欲しい(´･ω･`)

973 ：Socket774 ：2019/06/30(日) 16:26:22.14 ID:fQEDJFiP0.net

１Tストレージを４Kクラスタでアドレッシングしても高々１GB程度
いくらでも追尾は可能なんだからどうにでもなる
どうにでもなるがどうやっても一長一短でてくるんだからどうにもならん
ホストの空き時間を使ってローカル自律で並べ替えも考え方の一つだが
SSDのような制約もないいくらでも上書き可能なのに
ローカルアドレスを制御するデメリットはでかすぎると思う
OSのドライバ層に並べ替えを組み込むのがスマート

974 ：Socket774 ：2019/06/30(日) 16:39:22.07 ID:fQEDJFiP0.net

デフラグツール（SMR専用の）で並べ替えても
自律で並べ替えても　
総時間は同じ

操作者がその時間を認識するか
認識しないかの違いだけなのである

975 ：Socket774 ：2019/06/30(日) 16:55:02.00 ID:HTgv84nO0.net

次

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

976 ：Socket774 ：2019/06/30(日) 17:31:02.20 ID:aPjClehR0.net

>>968
どういう例えなのかよくわからんｗ

>>971
大分曖昧になってきたねｗ
推測を許さないと断片化に気をつけようというようなアドバイスもできなくなっちゃうからなあ。
何が事実でどこからが推測なのかを明確に線引きするのは難しいんだよ。

あなたの希望を叶えるのは初心者スレなんじゃないかという気もする。
上から目線で申し訳ないが技術話についてこれない人向けの。

>>972
それが問題だとわかっているなら、
そういうレスをする人にピンポイントで注意すればいいんじゃないかな。
可能性として話してることを、理解もできずに全否定する人なんかも
ついでに叩いてくれると個人的に助かるｗ

977 ：Socket774 ：2019/06/30(日) 17:36:43.45 ID:aPjClehR0.net

>>973-974
だから、そういうのが実現すれば理想的なのはみなわかってるんだけど、
現実はそう動いてないのよ。
それどころかメーカーは SMR であることを隠蔽してる有様。
なので、なるべく CMR（SMR との対比で生まれた言葉で普通の HDD のこと）同様に
使えるようにするにはどうするべきかね（どうやってんのかね）って話がメインになってる。

978 ：Socket774 ：2019/06/30(日) 21:07:17.01 ID:UpMBc+KYd.net

>>962
RAIDコントローラから切り離されるリスクというか
>>11 よりSMRは一部RAIDでは使えないってのは現状では事実みたいだよ

979 ：Socket774 ：2019/06/30(日) 21:15:37.72 ID:vbg/dU/G0.net

>>961
実際には HDD 内の管理領域はそんなに更新されないって >>591 で言ってるみたいだけど
MC にキープってのも何を判定してキープするのか謎

980 ：Socket774 ：2019/07/01(月) 02:07:51.69 ID:BdX34jkc0.net

次スレも立ってることだし、たまには相手してやるか。

>>978
Drobo のは動作保証はできないという意味で、機器側としては真っ当な主張だな。
タイムアウトを長めに設定できるようにする道もあるが、そんなのはポリシー次第だ。

HDD メーカーが SMR ということを隠して売っているのだから、
本来は CMR 同様に使えなければならないという話なのがわからないのか？
何が「事実みたいだよ」だ。物事の本質が見えてないんだよ。

>>979
>>591 の最後の段落は理解したのか？
CMR ですら無視できないロスになるのである程度はまとめてるって話だろうが。
少し減ったところで SMR にとって大変であることに変わりはない。
字面だけ見て薄っぺらな判断しやがって。
何が「そんなに更新されないって〜言ってるみたい」だ。書き手への侮辱だぞ。

二行目については聞き飽きたわ。いい加減にしろ。

まったく、相手やめたのをいいことにちょこちょこ過去レスにまでイチャモン付けやがって。
なんとかこちらの間違いを指摘してやろうとか考えてるなら、
そんなことやってるからいつまでたっても正解に近づけないんじゃないのか？
まあ、悪意もなく純粋に知的好奇心だけで動いてるようにも見えるしよくわからんが、
いずれにせよ大迷惑になってることにいい加減気付いてくれ。

981 ：Socket774 ：2019/07/01(月) 02:09:08.60 ID:BdX34jkc0.net

このスレを最近訪れた方へ。
やたら上から目線に見えるとは思いますが、これまでの経緯あってのことですので、
スレに目を通したあとでの判断をお願いします。
もちろん興味ないなら気にせずスルーで。

982 ：Socket774 ：2019/07/01(月) 08:42:48.63 ID:I+uGWrYkd.net

>>980
少し減ったところでって >>591 はwin7だと6万ファイル書いた時の
HDDへのコマンド発行数が5万だったって話でしょ？
管理情報を書くのが大変って感じがしないけど？

983 ：Socket774 ：2019/07/01(月) 08:57:50.92 ID:I+uGWrYkd.net

>>980
聞き飽きたというかキープ判定はSMRがアクセス解析してやるって言う抽象的な話だけで
それ以上の具体的な事は語られて無いと思うんだよね
SMRがアクセス解析するってので色々疑問は尽きないけど、例えば
NTFSで暫く使った後にFAT64にクイックフォーマットしたら
FAT64使ってるけどSMRはNTFSの解析結果で動くんだよなーとか

984 ：Socket774 ：2019/07/01(月) 14:16:28.30 ID:BdX34jkc0.net

>>982
まだわからんのか？
５万回ってことはバンドひとつの書き換えが１秒だったとして最悪５万秒かかるってことだぞ？

で、現実には有り得ないが、もしもすべての書き込みが何であるのか把握できるなら、
ディレクトリ以外の管理情報はそれぞれ数回からせいぜい数十回、
ディレクトリについてはファイルと一緒に書き込めるので実質０回となる。

が、未来予知が不可能なのはもちろん、どれが管理情報なのかすらわからないんだから、
アクセス解析により予測し理想に近づけるしかない。

こんなような話は何回もしてるが、お前の反応はいつもこうだ。
「（勝手に理想に近い動作をする仮定で？）大変じゃないんじゃない？」
そのためにはアクセス解析が必要と説明しても
「（なぜか理想に近い動作をできる仮定で？）そんなの必要ないんじゃない？」

どうすれば伝わるのかもうわからんよ。
相手が間違ってる前提でなんとか辻褄が合うように考えてしまう腐ったロジックでもあるのか？

985 ：Socket774 ：2019/07/01(月) 14:25:11.26 ID:BdX34jkc0.net

>>983
フォーマット変更なんてせずともディレクトリを削除しただけでそういうことは起こり得る。
Trim があれば大丈夫だが（アドレス変換なしでも有用な例）、デフラグで移動したとかね。
しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。

具体的に何をするかは、繰り返しアクセスされたり最近アクセスされたものは
またアクセスされる可能性が高いだろう予想するというような一般的なことには言及したぞ。
それ以上は色々考えられるのではっきりしたことはわからないが、
自分が作るならこんな感じかなと妄想したことはあるので例として言ってみようか。

・ライトアクセスで +10 リードアクセスで +1 のポイントを与える
・時間経過もしくは総アクセス回数に応じてポイントを少しずつ減少させる
・キャッシュエントリが不足した場合、ポイントが小さいものから処理する

古過ぎる情報をあまり覚えていても前出の件のような場合に邪魔になるので
ポイントには上限を設けたほうがいいと思う。

「処理する」は「捨てられないものを瓦書きして捨てられるものにする」
と「捨てられるものを捨てる」のいずれか（場合によっては同時）で、
基本的には後者が先に行われるが、
ポイントが非常に高い場合には残しておいたほうがいいかもしれない。

また、アドレス変換なしでキャッシュ管理がセクタ単位の場合、
>>742 でも触れたようにバンドごと残しておけば書き換え時にメリットがあるものの
なるべく沢山キープするという戦略も考えられるので
ポイント管理をセクタ単位にするかバンド単位にするかは微妙。

あくまで妄想だからなｗ

986 ：Socket774 ：2019/07/01(月) 18:26:58.04 ID:I+uGWrYkd.net

>>984
すまん書き方が悪かった
>>591 はwin7で6万ファイル書いたらHDDには全部で5万コマンド発行されて
そのうち管理情報アクセスが1.3万回という話だそうだ
なので1ファイル1回未満の書き込みにそんなに必死になる必要ある？という疑問になる
というかレス書いた当人かと思ってたが違うのか

987 ：Socket774 ：2019/07/01(月) 18:56:53.85 ID:4rvmHplf0.net

嫌・・・瓦は嫌ぁぁあ

988 ：Socket774 ：2019/07/01(月) 20:58:33.23 ID:vK2oMpqi0.net

ヘリウム怖い・・・

989 ：Socket774 ：2019/07/01(月) 21:58:42.31 ID:I+uGWrYkd.net

>>985
古いデータを捨てるならポイントと一緒にタイムスタンプも取っておかなくてはならず
それを全バンド分持ち続けることになり
そんなもの持ってるからフォーマットしても論理的に初期化されないぶっ飛んだHDDになると
このスレも終わりだから言っとくとアクセス解析とか言い出す前は頭良さそうだったのに
なんでアクセス解析云々言いだしてこんなんなってしまったのか不思議でしょうがない
別人なのかな？
アクセス解析なんて理解してない俺だけしか触れてないって所は察しても良い気はするが

990 ：Socket774 ：2019/07/02(火) 02:25:21.18 ID:U4gz3FWT0.net

>>986
いや、本人だよ。
ファイルシステム的に必要なはずの回数よりは少ないが極端に少ないわけでもない
ということが大事で具体的な回数は重要ではないので覚えてないし確認もしなかっただけ。
１万回だとしても大変なことには変わらんだろう。１万秒が何分なのか計算してみ。

あと、ちょっと間違えてた。お前とはまっさら状態での考察ばかりしてたので（言い訳）。
一般的にはディレクトリが割り当てられるクラスタがファイルと隣接するとは限らないので、
二段落目は正しくはこうかな。

〜管理情報はそれぞれ数回からせいぜい数十回、
ディレクトリについてはファイルと一緒に書き込めて実質０回となる場合もある。

991 ：Socket774 ：2019/07/02(火) 02:37:55.22 ID:U4gz3FWT0.net

>>989
いや、タイムスタンプはいらない。
アクセス頻度とアクセス時刻に重みを持たせつつひとつにまとめるためのポイントなんだよ。
「少しずつ減少させる」で何が起きるのか考えてみ。

「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
そもそも、予測が当たれば効率が上がるというだけで、
外したところで大きな問題になるわけでもない。

最後の一文はこちらに察しろって言ってるのか？　なら逆だ。
おかしいことを言ってればほかからも突っ込みが入るはずだ。
ましてやお前を叩いてるんだし怒る人だっているだろう。
そうならないのは、どこまでやるべきかはともかく、
アクセス解析という考え自体に異論のある人はいないということなんだよ。
常識レベルの知識だし、キャッシュという概念から自ら思い付く人だっているだろう。
理解はできないが「ふーん、そういうもんなんだ」みたいな人もいるかもしれない。

お前の問題は、理解できず明確な理由をもっておかしいと指摘できるわけでもないのに、
「そんなことする必要はなさそう」という曖昧な理由で否定するところだ。
理解できないなら必要ないかどうか判断なんてできないんだよ。
掛け算できない人が「繰り返し足しゃいいんだから掛け算なんていらなくね？」
って言ってるようなもんだぞ？

992 ：Socket774 ：2019/07/02(火) 07:20:57.23 ID:NwN6N1O/0.net

>>991
それを言ったらお前は管理情報書き換えがなんとなくヤバそうっていう曖昧な理由で
フォーマットしても初期化されないユーザーもメーカーも望まない
致命的な欠陥HDDが作り上げられてるって吹いて回ってるんだよ

1万回でも大変っていずれにせよファイル本体で4万回書かなくてはならないのにどこが大変なんだっつーね
しかもアドレスが同じなら瓦書き時にMC上でマージされて消えるし

993 ：Socket774 ：2019/07/02(火) 08:18:38.14 ID:Snmjx7Gd0.net

>>992
5万秒のうち1万秒は20％。4万秒が既に大変ってのはyesですが20％は結構な量→200Mで書けるHDDの期待値が160Mになる

解析してるかどうかは判らないし俺様理論である事には変わりませんが「大した事無い！やってる訳無い！」ってのは乱暴と思うよ。

まぁコスト(bugコスト含む)の面でヤってないと私個人は思いますがw

994 ：Socket774 ：2019/07/02(火) 08:42:38.28 ID:khR3/b64d.net

>>993
ああ、やっとそんな事やってるわけがないって事がわかって貰えたか
いやある程度の知識と読解力が無い人に理解してもらうのは大変だな

995 ：Socket774 ：2019/07/02(火) 09:49:11.87 ID:XSCJb4TVd.net

>>994
ん？
念のためですが、私は別人で かつ個人的意見はやれば効果あるだろうがコスト面でヤってないんじゃね？ですよ？

996 ：Socket774 ：2019/07/02(火) 10:07:22.22 ID:U4gz3FWT0.net

>>992
なんとなくヤバそうなんてレベルじゃないんだよ。
１万秒は計算したのか？　３時間近いんだぞ？
じゃあ、ファイル本体は４万回で４万秒で１１時間かかるのか？　おかしいだろ？
お前は答を直接書いても頭に入らないようなので自分で考えてみろ。
落ち着いて考えればどこで間違えたかわかるはずだ。

やっぱり（少なくとも今の）お前は相手の間違いを見つけてやろうということに必死で、
肝心なことに頭がまわってないように思えるな。
フォーマット時に不適切な挙動が発生する可能性に気付きそればっか考えてるんだろう。

＞しばらくは誤判断され不適切な動作も起きかねないがそのうち忘れるので問題ない。

＞「ぶっ飛んだHDD」にならないような考慮もしてある。四段落目ね。
＞そもそも、予測が当たれば効率が上がるというだけで、
＞外したところで大きな問題になるわけでもない。

と説明したのに、「理解できず明確な理由をもっておかしいと指摘できるわけでもないのに」
「致命的な欠陥HDDが作り上げられてる」とか妄想して攻撃できてるつもりになってるわけだ。

997 ：Socket774 ：2019/07/02(火) 10:08:13.16 ID:U4gz3FWT0.net

>>993
あなたも考えてみてね。
「ファイル総サイズ392,336,035バイト」書き込むのに１４時間かかってどうするの？

バグの心配をするなら、一番古いものから処理するだけでいいんじゃないかな。
単純だがこれもアクセス解析の一種。結果的にアクセスパターンを追ってることになるからね。
これだけでも単なるコピー程度なら無駄書き換えは大分減らせると思うし、
彼が気にしてる問題もすぐに解消するので欠陥とか言わせないｗ

998 ：Socket774 ：2019/07/02(火) 10:13:26.59 ID:U4gz3FWT0.net

>>992
あ、念のためだが、お前がその記事を持ち出してきたのでそれに付き合っただけで、
メディアキャッシュに丸々入り切るサイズなのだからとくに工夫する必要もない。
全部溜めてから吐き出せば理想的な書き込みができるとか馬鹿なことを考えるなよ？
最終的には、溢れる可能性がある規模のケースに置き換えて考えないと意味ないからな。

念のためだが「この記事を持ち出したのはそっちだ」とかいうおかしな反応が予想されるので、
管理情報をある程度まとめ書きしていることの根拠として出しただけだと先手を打っておく。
流石にないかｗ

999 ：Socket774 ：2019/07/02(火) 12:19:07.79 ID:khR3/b64d.net

>>993
ああ、別人だったのか
こんなの触るの俺だけかと思ってたからてっきり当人が改心したのかとw
そう言いながら自分はやるわけないと思ってるなら同じ事じゃないか？w

1000 ：Socket774 ：2019/07/02(火) 15:48:49.81 ID:khR3/b64d.net

>>996
まあ普通に考えたら5万秒、4万秒共にアウトか共にセーフかどちらかで
前者ならアクセス解析ではなく別の対策をするべきじゃないかと
アクセス解析では5万秒を4万秒にする事しか出来ないでしょ？
5万秒はアウトで4万秒はセーフだからアクセス解析でなんとかすべき
なんて方がアクセス解析したい人の都合の良いサンプルの抜き出しじゃないかとね
10万秒と8万秒でも同じ事
結局20%しか向上は認められないわけだし
MCのサイズを調整した方がお手軽で現実的ではないかと

1001 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。