【参照】SSDとP2Pにおける注意点

改稿.2015/08/02...20150801...

＞　P2Pの受け取りをSSDに任せる場合
＞　NET回線がSSDの書き込み速度を上回らない限りDiscCashは発生しない


　‥P2P通信を介したアクセスが猛烈に集中した場合
　HDDなら途端にアームの動きが追いつかず、何もできない状態に陥るが
　SSDの書き込み速度は十分に上回るので、スペック的には問題は発生しないように見える。

　ただし

　SSDの場合、空白域に余裕が無いなら‥大きなロスを発生させるばかりになる。
　SSDの書き込み速度がほぼスペック通りだとしても
　再空白にする上での要時間については、全く公開されていない。

　（公開されていないと言うことは、そこを目玉にするような開発は前提に無いように思われる）
　（これは素人解釈だが、強いて言えば、３つあるNANDタイプの差がどうかぐらいなのだろう）
　（‥お互いに似通った製造のNANDメモリーを使用する限り、公開する意味がない）


＞　SSDが記憶域を再空白にするには、かなりの時間が必要だ


　だから、SSDの空白域が、継続的なアクセスの規模に対して十分に余裕が無い‥且つ
　メモリーが十分にあるにも関わらず、使用するP2Pアプリにそれの使用を許可しないままにあると
　通信アクセスの集中の度合いによっては、DiscCashの必要を及ぼす。


　‥ところが、直接にSSDに書き込む作業は、削命の点を考えるとあまりよろしくない。


　特に‥ダウンロード情報のファイルサイズを領域予約確保した場合
　SSDはHDDと違って、その指定した物理領域に上書きするわけではない。
　改めて余白に書き改め、その間に以前の箇所を再空白にする作業を行う。
　（‥これは、SSDにおいてHDDのアームの動きが先か後かの違いとも言えるべき回避不可能な事象だ）

　公表スペックを十分に得たいのなら、十分な空白の確保が欠かせない。
　少なくとも、SSDの容量の半分までを最大書き込み予定ファイル域の限度に留める次第になろうか。
　（‥それでも断片化は避けられない状況になりそうだ）


＞　‥つまり、P2Pからの情報をSSDに直接書き込むことを狙うと


　領域予約確保したファイルの大きさに対して、常に二倍の容量で書き換えを必要とし
　削命に与えるダメージを常に二倍に固定してしまうことになる。
　（さらに、SSDはブロック単位で書き換えるため、断片化を伴うならどう考えても高くつく）

　ゆえに

　P2P通信による対象ダウンロードは、HDDに書き込むことを前提にすべきだ。
　逆に、SSDにDiscCashの領域を大きく与えた方が、結果的に削命の延長に繋がることになる。
　‥時には、数百ギガのキャッシュ領域を変動指定した方が効率が良いと言うことにもなるだろう。
　（気分としては、変動ではなしに固定にしたいところか‥固定の方が若干管理処理が減る）
　（固定と変動の選択幅の違いが削命にどう現れるかなど知らん）

　断っておくが‥OS側のキャッシュ域の制限幅がどうなっているかは知らん。

　まずは、サイズの大きなSSDを用意して、
　さらにキャッシュ用ディスクの数を増やして、キャッシュ域を確保する必要にもなろうか。
　（‥そこまでやる必要があるかどうかについてなども知らん。是はあくまで一つの意見である）
　（‥ビットコインのような演算を請け負おうと思えば、当然の思索かと）
　（‥できるなら、メインメモリーを増やすことを合わせて検討すべき事だ）