chapter344, [SORA] draft: renewal Whitepaper 6, About Business model

6, About Business model

  • So far, we have explained an overview of analysis to the sectors of a drive by a Blockchain.
    これまで、ブロックチェーンによるドライブのセクタに対する分析の概要について説明してきました。
  • Sector analysis is analysis for drives. In fact, we have been researching scan and recovery software for more than 10 years since January 2009. Then, will implement a Blockchain.
    セクタ分析は、ドライブの分析です。 実際、2009年1月から10年以上スキャンおよびリカバリソフトウェアを研究してきました。その後、ブロックチェーンを実装します。
  • By the way, on the other hands, the main point of view is the Business model. We consider to “simple is the best” here.
    ちなみに、一方で、主な視点はビジネスモデルです。 ここでは「シンプルが一番」と考えています。
  • First. Building a mechanism that consumes a certain amount of coins when copying “operator”. This is equivalent to a “network fee”. This provides a decentralized mechanism that supports appropriate rewards for miners while preventing over-access due to spam.
    その一。「作用素」をコピーする際に一定量のコインを消費するメカニズムを構築します。 これは「ネットワーク料金」に相当します。これにより、スパムによる過剰アクセスを防ぎながら、マイナーに適切な報酬をサポートする分散型メカニズムが提供されます。
  • Then next, you can get a license to use up the data recovery feature several times by spending coins. This is equivalent to a limited using license of the perpetual use license ($70 – $160) currently on sale.
    次に、コインを使うことで、データ回復機能を数回使用するためのライセンスを取得できます。 これは、現在販売されている永久使用ライセンス($ 70〜 $ 160)の限定使用ライセンスに相当します。
  • Only these two. It’s so simple, but there is a amount of demand. Because, year by year, the total number of drives used all over the world is increasing. We will challenge those drives with this business model.
    この2つだけ。 とてもシンプルですが、かなりの需要があります。なぜなら、世界中で使用されるドライブの総数は年々増加しているからです。このビジネスモデルでそれらのドライブに挑戦します。
  • In order to respond to high liquidity, we would like to constantly negotiate with Exchanges and building the best environment. (e.g. FinexBox: Finex drive chain)
    高い流動性に対応するため、常に取引所と交渉し、最良の環境を構築していきたいと考えています。(例: FinexBox: Finex drive chain)

chapter343, [SORA] draft: renewal Whitepaper 5, Concept of chain in operator

5, Concept of chain in operator

5-A, Drive has huge number of sectors
5-A, ドライブには莫大なセクタ数があります

  • The drive is made up of a huge number of sectors, therefore
    the speed will not increase when they copy operators on a scan by sector-by-sector basis.
    ドライブは膨大な数のセクタで構成されているため、セクタごとの検査で作用素をコピーする場合、速度は向上しません。
  • Therefore, we have implemented a mechanism to be operated chain in operator.
    したがって、作用素を連鎖させるメカニズムを実装しました。
  • This mechanism is so similar to the modifier’s checksum calculation.
    このメカニズムは、モディファイアのチェックサム計算と非常によく似ています。
  • If this logic implemented, after the operation of the operator A, the operator A’ to be used next can be extracted from the operation result AH. That is, the concept of “chain”.
    この論理を実装すれば、作用素Aの演算後、演算結果AHから次に使用する作用素A’を抽出することができます。 つまり、「連鎖」の概念です。

5-B, e.g. equality operator
5-B, 例えば、恒等の作用素

  • Below, A and A’ are operator, then H1 and H2 are a normalized object (e.g. matrix)
    以下、A, A’は作用素で、そして、H1, H2は正規化されたオブジェクトです。

SSD/NVMe scan -> get H1 as result
Blockchain -> OP_CODE -> copied A as result
operation AH1
if H1 = AH1 -> A is equality operator -> A’ = A
SSD/NVMe next scan -> get H2 as result
operation A’H2

ビッグデータ解析結果反映を本日再開いたしました – IUEC

入れ替えたサーバの安定性を確認できましたので、ビッグデータ解析結果反映を本日再開いたしました。
従来は6時間おきの解析でしたが、今回より、3時間おきとなりました!
※ 総合判定に限り、一旦リセットいたしまして、再度、はじめから導きます。
理由 => この部分の判定にメーカ様別を採用した結果、少しの量でも反応してしまい、なかなかワーニングが消えない状態となりました。総合判定の情報が扱い難く、大変申し訳ございません。この失敗により選別方法が把握できましたので、今回、改良いたしました。
>> こちら => https://www.iuec.co.jp/driveinfo/

なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/

ビッグデータ送受信&解析サーバ(MN)の入れ替えを完了いたしました – IUEC

ビッグデータ送受信&解析サーバの入れ替えを完了いたしました。
※ ビッグデータ送受信&解析のパフォーマンスが改善しております。
ただ、クライアント側の内部処理が古いままの場合、サーバ側の性能向上&改善だけでは倍程度で収まる感じです。
最速解析(分散同期)には、クライアント側のアップデート(最新版)が必要となります。
現在、しっかり進めておりますので、なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/

大幅に改良(+バグ修正)いたしました各機能について、その詳細をご紹介いたします。 ※ 最終デバッグが完了次第、リリースいたします。 – IUEC

1, 仮想デスクトップで使い勝手が良くなる調整を行いました。
※ 例:ダイアログが開いた状態からバックグラウンドさせる場合、タスクバーまたはタスクトレイに退避させる事が可能となりました。
2, ドライブの認識系統を2系統にわけて、認識順序を選択できるようになりました。
※ 例:読み書きは安定するが、コマンドが不安定なUSB接続外付け型(USB変換チップの相性問題)の場合、読み書きをオン、コマンドを一部限定に設定して、安定な動作を実現できます。
3, 不良セクタの修復機能が大幅に変わりました。全ての種類のセクタに、修復作用を試みる機能を実装いたしました。
※ これは、分散解析より得られます「分散故障情報」から、セクタの危険度を判別できるようになったためです。比較的安全なセクタから「ランダムに修復」する機能になりました。
4, ストレージ故障予測機能を廃止いたしました。
※ こちらは、ドライブ情報の分散解析に変わりました。これにより、常駐させる必要がなくなります。
時々、完全スキャンまたは統計スキャンを実施するだけで、その結果を自動的に分散解析に乗せて、待つだけです。
また、この待つ間も起動させておく必要はありません。結果の方は、後から同期させて取得できます。

その他、バグの修正(サポートおよび掲示板でご指摘いただきました要素全て)、高速化(特にマイニング方面)を行っております。 なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/

FromHDDtoSSD ドライブ情報の分散解析 最終デバッグ中となりました。長らく更新できず、大変申し訳ございません。また、ご指摘いただいておりました他のバグも修正しております。- IUEC

やっとじゃな。
一箇所での集中解析から、分散解析に移行するため、かなり大幅な変更となった。
具体的に、どのような感じなのでしょうか?
例えば、S.M.A.R.T.の0x05が上昇した場合、その上昇は本物なのかどうかの「承認作業」が実施できるようになる。
ビッグデータの送受信を有効にしている場合、検査完了と同時に承認作業に移行する。
ドライブ正常性の承認作業となるから、一定数の承認が得られれば問題なし、未承認なら交換、となる。
でも、大幅な仕様変更となると、移行作業の方はどうするのでしょうか?
移行作業は不要、単に上書きインストールするだけじゃ。
実は、3年くらい前から分散解析のための共通分散データベースを持たせてあるんじゃよ。
このため、同期作業のみで済むから、特に移行作業とか・・面倒な作業は一切ない。
検査後に「ドライブ分散解析ダイアログ」を開けば、自動的に承認作業に入り、検査結果の裏付けを行う仕様になる。
今回は何とかcoming soonのまま(^^;にならないように頑張っている最中じゃ。

https://www.iuec.co.jp/

ドライブ状態情報の分散解析システムをクライアント様用(FromHDDtoSSD)に2018年春に実装 ※ S.M.A.R.T.コンセンサス – IUEC

ドライブの大容量化が進み、検査ならびに復旧方面についても、大きな変革が求められる時期になりました。
そこで、作業の大部分(重要かつミスが許されない、データを取るロジック)をしっかり自動化するAI復旧が台頭してきました。 ただ、AI復旧はAIを活用するため、これを動かすための土台となる規則(ルール)が必要になります。たとえば、「交通ルール」や「駒の動かし方」などが、この規則(ルール)に相当いたします。
そして、ドライブの復旧に関する規則です。これがしっかり決まらないと、AIも本領発揮できません。
この規則(ルール)を、秒単位でドライブの状態を定めていくS.M.A.R.T.コンセンサスに託したいと考えております。

旧式(研究段階)のS.M.A.R.T.コンセンサス
※ ロジックが「全探索方式」となっていたため、使い勝手が悪かったと思います。大変申し訳ございません。
Build:3400より新方式の「分散マイニング方式(本論述の主旨)」となります。マイニング1回分のCPUを拝借いたしますが、その対価として解析結果をお渡しいたします。

トランザクション&統計スキャン実装

■ S.M.A.R.T.コンセンサス(解析)=>AI=>ドライブに対する処理=>AI=>S.M.A.R.T.コンセンサス(マイニング)
この流れを繰り返して、壊れたドライブから、少しずつ安全にデータが復旧される仕組みとなります。
また、統計スキャンについても、S.M.A.R.T.コンセンサス(解析)がスキャンの度に必要となります。
このため、効率良く解析可能な本システム(分散解析システム)稼動まで実装できず、大変申し訳ございません。

https://www.iuec.co.jp/

SanDisk製 240GB SSD (パフォーマンス重視:おすすめ) 型番:SDSSDA-240G-J26 – IUEC

先日は臨時休業の件、大変申し訳ございません。
※ 前日まで話をはぐらかされていた(^^;ため、急になってしまいました。
実験が上手くいったのであれば・・・素直に言えばよいものを・・(^^;

本日はSanDisk製 SSDのベンチマーク結果をまとめました。
また、WD製240GBの再調査および、総合評価(15段階)を追加いたしました。今後ともよろしくお願いいたします。

パフォーマンス 4 / 5
動作安定度 3 / 5
コスト面 5 / 5
総合評価 12 / 15

10回連続、ベンチマークを実施いたしました 。

10回、続けて乖離率ベンチマークを実施いたしました。
※ 途中から急激にグラフの形状が変化しております。乖離率は問題ないため、サイズ加重平均テストD&テストFの伸びが大きく、パフォーマンスを取りつつ安定させていると解釈できます。

https://www.iuec.co.jp/

乖離率ベンチマーク:https://www.iuec-recovery.jp/?p=948

ドライブ故障統計を活用する「統計スキャン」 近い時期にリリースいたします。 ※ 現在、地道に入力いたしました壊れかけドライブの統計から学習中です。 – IUEC

一番下にあるグラフが「動作指標」となります。劣化の判断ならば、スキャンの完了まで待つ必要はありません。専用の「動作指標」が付属し、それを一目見るだけです。この仕組みは、統計的にドライブの弱い部分と判断された所に、少し強めの負荷を自動的に与えます。正常なドライブは問題ありませんが、劣化が進んでおりますと、ほぼ確実に影響が出てきます。それを「動作指標」としてキャッチしております。

https://www.iuec.co.jp/

[R.E.C.O.A.I.] AI vs 復旧担当者(自分か…) その1 – IUEC

本機能によるスキャンロジック(R.E.C.O.A.I.)の実装(研究)自体は2011年頃からはじめたのですが、はじめのうちはクローン装置+α程度で、手作業による指示の方が上でした。

それが・・、3.0TBが一般的に普及し始めた2014年頃から急に精度が向上してきまして、今では手作業にて数ヶ月を要する複雑な故障を軽々とスキャンできる所まで成長いたしました。
※ Seagate製の・・あの厄介な故障による動作不安定や、プラッタに損傷を負い動作が安定しないドライブなどのスキャンを問題なく完結できますので、精度面は問題ない水準です。

このため、お客様より手作業のご要望が無い限り、こちらのAIで対応いたします。

まず、データ復旧サービスの流れをご説明いたします。

ドライブ検査=>クリーンルーム作業=>データスキャン作業=>データ再構築作業=>データ移転作業

この5工程を行いまして、各データを復旧いたしております。(物理障害の場合)
このうち、AIが担当する作業は「データスキャン作業」「データ再構築作業」「データ移転作業」となります。
そして、最も難しい作業は「データスキャン作業」となります。クリーンルーム作業ではありません。
※ クリーンルーム作業は「内部の部品を交換するだけ」なので、特別に難しい作業ではありません。
※ 次の過程で実施いたします、データスキャン作業が難しいです。

なお、はじめに実施いたします「ドライブ検査」はとても大事です。
表向きは論理障害のように見えて、隠れ物理障害というパターンがとても多いためです。
失敗が許されない復旧作業では、この検査が大事なんですが・・・こちら(^^;

■ 2011年よりはじめましたヘッドレストレーション機能

■ 最近(^^;
※ 上:弊社業務用のソフトウェア(ドライブスタビリティコントロール)
※ 下:こちらで公開しておりますAI完全自動ドライブ復旧システム(ベータ版)

https://www.iuec.co.jp/

明日に続きます…

[R.E.C.O.A.I. その4 学習側] 待機中の学習処理 – IUEC

壊れかけドライブ(復旧対象)をAIから受け取った結果通りにスキャン系が処理している間も、有効に活用します。
※ 特に「エラー訂正指示」が出た場合は、数秒等の空き時間が発生いたします。

この間は、優先度が低めの情報を処理してしまいます。

「学習状況を表示します。155 – 134581 result_0」と一番下から出ておりまして、解析の結果、使える見込みが高い情報が取り出せた場合は「result_1(受理)」となります。こちらの解析は元々が優先度が低めゆえに、なかなか「result_1(受理)」とはなりませんが、それでも僅か1回のミスで破損してしまうかもしれない「壊れかけドライブ」を扱いますので、慎重に慎重を重ねていきます。

なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/

[R.E.C.O.A.I. その3 ドライブ側] 測定結果+スキャン結果から学習 – IUEC

第一候補をconst_iteratorでスキャン系に渡しまして、それからしばらく待ちますと(^^;
(壊れかけなので時間を要する場合が多いです)、
その候補にてどのセクタがどのような形でどう収まったのかを示すスキャン結果(map等)を戻してきます。

そしたら、それらも結果として放り込みますと学習が始まります。

https://www.iuec.co.jp/

[R.E.C.O.A.I. その2 ドライブ側] 測定結果の選別2 – IUEC

昨日の機能だけでも、これを完全スキャン系に包含させますと、検査機能向上が見込めます。

完全スキャンから常時出力される結果を統計として常時取り出し、昨日の機能に放り込みます。
大事な部分が自然と残る形で処理されますので、メモリを圧迫せずに、ドライブのスキャン結果を統計として積んでいくことができます。

あとは、最後の判定前に、取り出せた第一候補・第二候補を評価関数に渡して、最終結果を得る事になります。
※ 完全スキャンの結果生成処理は、時間的に余裕がありますので、第二候補も使います。

また、完全スキャン終了後に、他のドライブの統計をビッグデータとして放り込みます。
これにより、型番別にてより詳細な結果を得ることが可能となります。

これらの機能を「統計スキャン」として実装中です。近いうち、リリースいたします。
また、フリーエディションに完全対応いたします。お気軽にお試しいただけたら幸いです。

なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/

良いドライブと悪いドライブ – IUEC

テクニカルサポートでよくお問い合わせいただきます「良いドライブ」と「悪いドライブ」についてまとめました。

良いドライブ

ドライブの劣化状況をS.M.A.R.T.等に刻々と報告いたしまして、データの安全性を重視

悪いドライブ

劣化状況等は一切報告せず、故障する直前まで完全な正常を振る舞うドライブ

しかしこれが、状況を難しくしています。

ドライブの劣化状況をS.M.A.R.T.等に刻々と報告いたしますと、ネガティブに捉えられてしまう事があります。
いわゆる「短期間で、これだけ劣化するこのメーカは・・ダメなんじゃ・・」みたいな感触です。

そして、「劣化状況等は一切報告せず、故障する直前まで完全な正常を振る舞うドライブ」の存在です。
故障直前までは「完全な正常」を振る舞うのですから、なぜかこちらがポジティブに捉えられてしまう現象が起きます。
正直な方は劣化指標が上がっていて良くないが・・、こちらは完全な正常値で問題ない、みたいな流れになります。

さらに、この悪い方にデータを預けてしまいますと、中々、バックアップをとらせてもらえません
その理由は・・、「完全な正常(まだまだいける)」を振る舞われると、心理的に「大丈夫(余裕)」という気持ちが強くなってしまい、中々、時間のかかるバックアップに手が出なくなります。このあたりはドライブに限らず、よくある話だと思います。

なにとぞよろしくお願いいたします。

https://www.iuec.co.jp/