[SORA] Happy New Year!

hello friends!
Happy New Year!

Well, development is continuing during the New Year holidays.

1, Add script for prediction processing to the basic functions (P2PKH, P2SH, P2WPKH, P2WSH).
2, We will add a transaction for quantum resistance. The size of the keys(CLPubKey, CLKey) will increase.

SorachanCoin intends to support the keys below:
CPubKey, CKey:
wallet of old core.(only supported random)
CPubKey, CFirmKey:
wallet of latest core.(both supported random and HD)
CLPubKey, CLKey:
wallet of quantum resistance.(only supported HD)

データ復旧機能に属します「バイナリダンプ」に、セクタ番号指定機能を加えました – IUEC

いつもお世話になっております。開発担当の矢野と申します。

データ復旧機能に属します「バイナリダンプ」に、セクタ番号指定機能を加えました。
これにより、セクタ番号をご指定いただき、その場所へ飛ぶ事ができるようになりました。

□ 統計スキャン・システムリカバリ導入の前に、不足しておりました機能の追加と、バグ修正を実施しております。
※ 次は、ヘッドレストレーションの改良・バグ修正および、不良セクタレストレーション(不良セクタ修復機能)が大きく変わります。なにとぞよろしくお願いいたします。

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

パターン受信に失敗する件、大変申し訳ございません – IUEC

いつもお世話になっております。開発担当の矢野と申します。

パターン受信に失敗する件、大変申し訳ございません。
Build:2050にてバグの修正を完了いたしました。
※ 受信設定の一部がパターンから取られておりまして、それが原因となっておりました。
インストール版ではパターン自体をソフトウェア側で持つため、これでも問題なかったのですが、
インストール不要版ではパターンを0から受信するため、何もない所(^^;から設定を取ろうとしていました。
ただ、初期化自体はされておりますので、各設定に0が入りまして、受信の待機時間が0になっておりました。
この場合、少しでも待たされた場合、受信に失敗いたしますので、これで上手くいかなかったと断定しております。

これからも、なにとぞよろしくお願いいたします。

※ ビッグデータ解析、いよいよ導入です

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

データ復旧機能(ファイルシステム解析)にビッグデータの取り入れをはじめました – IUEC

いつもお世話になっております。開発担当の矢野と申します。

いよいよ、データ復旧機能(ファイルシステム解析)にビッグデータの取り入れをはじめました。
特に、今回はファイルシステムの解析にも取り入れる方針となりまして、
ドライブへの負荷を出来る限り削り、壊れかけドライブを簡単に扱える環境に向けて大きく前進いたしました。

■ これで、「つなぎ復旧」、「ファイルシステムへのビッグデータ解析取り入れ」の2つを揃えました。
そして、3つ目がメインとなる「自動復旧機能 R.E.C.O.A.I.」です。こちらは学習機能を備え、セクタレベルで制御を抑え込みます。

モードレスダイアログでその制御を監視できる上、スキャン中に調整もできます。

この3つで壊れかけドライブの悪化を抑え、データを復旧する流れを見込んでおります。

これからも、なにとぞよろしくお願いいたします。

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

※ インデックスレコードの解析を優先

ソフトウェアのサポートについて書きます – IUEC

いつもお世話になっております。開発担当の矢野と申します。

本日はソフトウェアのサポートについて書きます。

ソフトウェアのサポートで、ドライブに関する内容(認識判断やお取り扱い)に関しましては、スクリーンショットのご提供をお願いいたしております。

その他、インストール先にあります動作ログも必要となる場合がございます。

これには明確な理由がありまして、ドライブに対する操作では「やり直し」が効きません。
このため、スクリーンショットおよび動作ログで現在の状況を見極めてから、サポートの方を実施いたしております。
※ 稀ですが、お急ぎの方で「この先どうすれば・・」と突然ご連絡を頂く事がございますが、環境・接続等が不明では、サポートは難しい(できない)です。
※ ご提供頂きましたスクリーンショットおよび動作ログは、サポートの目的でのみ利用し、完了後は破棄することを約束いたします。

S.M.A.R.T.ビュー・ヘッドレストレーションのスクリーンショット、動作ログ等から的確に判断し、サポートいたします。

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

開発状況や、アルゴリズム等について日々まとめていきたいと思います – IUEC

いつもお世話になっております。開発担当の矢野と申します。
開発状況や、アルゴリズム等について日々まとめていきたいと思います。なにとぞよろしくお願いいたします。
※ まとめようとして何度も挫折しておりましたが(申し訳ございません)、今回は、しっかりまとめていきたいと思います。

Ver2.1最終版の最終調整を行っております。
今回は復旧機能の大幅強化となりまして、出来る限り自動で早く結果を出せるように工夫しております。
データ復旧の機能は、大きく分類いたしますと、以下の3プロセスを早く処理できれば、総合的にも早くなります。

1:探索・回収
2:分解・並び替え
3:解析・生成

基本的に「地道」な作業です。特に目立つようなトリッキーなどがある訳でもなく(あったら欲しいのですが…)、
黙々と探索して手掛かりを集めて、それらを分解・並び替えして解析できる形に落とし、それらを解析してデータを出します。 ただ、地道なんですが、ここで上手くマネジメントできると、効率が飛躍的に上がるため、それを見つけるために日々没頭しております。
※ 矛盾しているように見えますが、トリッキーではなく、効率面のマネジメントを改善いたします。空いているCPUを働かせます。

最近のパソコンは実行コアが複数実装されておりまして、それらを同時に稼動させる事が出来ます。
基本はシングルスレッド(ただ1つの実行)で探索・分解・解析を行わせれば、間違いなく矛盾は出ず、上手くいきますが、効率は最低ラインです。

しかしながら、例として8つの実行コアがある場合、5つを探索・回収、2つを分解・並び替え、1つを解析・生成に振り分ければ、非常に早くなりますね。

でも、これが中々上手くいかないのです。例えば分解が早過ぎて探索が間に合わなければ、分解を担当したスレッドは待機します。待機というと良さげに見えますが、スピンロックと呼ばれる機構でCPUを空回しして、「遊んでいる状態」となります。
探索が早過ぎて分解が間に合わない場合は、物置(コンテナ)にそのデータが沢山入り込んでしまい、メモリを圧迫してしまいます。

では、事前に調べてから・・、といきたいのですが、その調べる過程にお時間を要しますので意味がありません・・・。
また、各コアにそれらの仕事が丁度良く振り分けられる訳ではなく、あくまでもOSが自由に振り分けてきますので、それに合わせる必要もあります。
それでも、偶然的に見つけたものや、それらの副産物で上手くマネジメントできるようになってきております。

1~3が上手く自動的に動くようになりまして、いよいよ拡張となる4番です。
4:ドライブ故障統計を導入

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