復旧日誌8, [HDD/SSD/RAID] ブロックチェーン活用 統計スキャンについて その1

いつもお世話になっております。

実在証明を秒単位で刻むことが可能なブロックチェーンを活用する、
統計スキャンの実装となります。

まず、データのアセプト……受理については、
ピア情報の受け入れと似たようなロジックを実装いたしました。
なぜなら、何度も似たようなデータが来てしまうと、
必要性がないデータの多重処理で重くなるためです。

同じドライブについて何度も検査する過程自体は正常な処理です。
そのため、似た統計は再送信せず、
統計処理で偏ったものだけをアセプトすれば、
自然に、欲しい故障情報だけが集まってくる、そういった仕組みです。

次に、この統計データは専用のデータベースに保管されます。
つまり、ブロックチェーンはトランザクションだけに留めております。
これで、サイズの制約はありません。

そして、専用データベースの整合性については、マイナーが担当いたします。
ブロック承認ロジックに、この整合性処理を追加いたします。
新規ブロック受理の際に、
このデータベースのハッシュ値確認を、承認条件の一つにいたします。

ただし、これをstrictモードにするとハードフォークが必要となりますので、permissiveモードで処理する見込みです。
つまり、この承認を乗せたサーバ……、すなわち、v1.4(安定板)またはv4.0以降(最新版)のサーバに切り替わったノードだけでも、十分な整合性は取れると判断いたしました。

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

復旧日誌7, [HDD/SSD/RAID] アフターコロナキャンペーンは一時停止いたします。

いつもお世話になっております。

本キャンペーンの方、今年のワクチンが効くのかどうか怪しい種まで出てきてしまったゆえに、一時停止する方向になりました。

ただし、サービス自体は維持したい(表向きから消すだけ)ゆえに、
新品ドライブが付属する等などの各サービス内容は変わりません。
そこで、再開次第、さらにサービスを追加していきたいと考えております。

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

chapter316, [SORA][BlockChain] Is LevelDB really fast to Blockchain?

We are currently checking performance of the blockchain that has migrated from LevelDB to SQLite.

In the case of LevelDB, in order to retrieve data using the sorted records arranged in a tree structure, it is necessary to deserialize unnecessary key data in order to apply conditions for exiting the search.

For example, if blockchain has 500,000 blocks, the key will be deserialized 500,000 times.
Then, since memcpy is called several times internally, it is a heavy process.
Furthermore, it will be strcmp in the comparison process. It’s heavy.

On the other hand, in the case of SQLite, the key can be specified in advance by the condition, so they only need to get the value.

復旧日誌6 [HDD/SSD/RAID] 10TBを超えたハードディスクの復旧について

いつもお世話になっております。
本日は、10TBを超えたハードディスクの復旧について、です。

現在、ハードディスクの方は「データ保管用途」向けとなっております。
一方、システム起動用途としては、迷わずSSDで問題ございません。

そして、このハードディスクの容量が急拡大しております。
4TBから8TBで踏みとどまっていたものが、
急激に増加を開始し、10TBは当たり前で、
そこから16TBなども拝見する機会が多くなってきました。

この域に達しますと、
データの最小単位となるセクタで、すべてを辿る方法による復旧は、
もはや現実的ではございません。
ピンポイントでドライブの状態を監視しながら、
データを取り出す手法のみが有効です。
2016年より開発してきました「自動復旧」と、
現在開発中の「ブロックチェーン」を組み合わせて、
ドライブの状態管理用データの取り扱いまで自動化する、
新しい試みを、ようやくリリースできる見込みになりました。

いま、自動復旧を担うFromHDDtoSSDについて、
MinGWと呼ばれるコンパイラへの開発環境移行を試みております。
Linuxで広く使われるGCCのWindows版が、このMinGWになります。
ブロックチェーンの開発がMinGWだったゆえに、
今後の中心部を踏まえて、MinGWへの移行を決めました。
特に問題なくWindowsAPIおよびWindowsDDKが利用できるため、
そのままで問題ないとは思いますが、
なにゆえにドライブへのアクセスが絡みますので、
しっかり検証後、ブロックチェーンを取り込んで「リリース」となります。

なお、ブロックチェーンの「活用」がメインとなります。
検査に限り、ネットワーク手数料として僅かなSORAが必要となりますが、
それでも、大幅な時間短縮が実現される見通しです。

まず第一弾では、ドライブの弱い部分を探索できるようなロジックが組まれます。10TB等の大容量をすべて検査するのは、時間がいくらあっても足りません。

そして、このようなドライブが沢山あると検査が面倒になって、そして、です……。

なお復旧系は、SQLiteに蓄積されたブロックチェーンを読み取って、
それらを手掛かりとするため、ネットワーク手数料は不要です。

もちろん、従来からある「完全スキャン」などは
ブロックチェーン非経由となりますので、今まで通りです。

そして、インストール不要版です。
パターンのダウンロードを必須としていましたが、今回、その全てを内蔵いたします。
それゆえに、ネットワーク非接続にて簡単にご利用いただける形になります。
※「ブロックチェーン非経由版」としては、これで完成です。

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

復旧日誌5 [HDD/SSD/RAID] PC-98などの古い産業用PCについて

いつもお世話になっております。
本日は、PC-98などの古い産業用PCについて、です。

まず、基本的に「環境ごと」復旧いたします。
よくご依頼いただく例として、NC工作機械に付属するコンピュータです。
これについては、データだけではダメで、
元の工作機械に戻すだけで、動くように整備する必要がございます。
それはすなわち、配線を戻してボタンを押すだけです。

復旧日誌4 [HDD/SSD/RAID] リビルドについて

いつもお世話になっております。
本日はリビルドについて、です。

リビルドの前に、以下の二点を必ずご確認ください。
1、少しでもデータが閲覧できる状態かどうか
2、すべてのドライブが動いているかどうか

まず1です。
少しでも閲覧できるのなら、その見える限りで構いません、
出来る限りのデータのバックアップを「先に」お願いいたします。
リビルドは成功する保証が「ありません」。これがこの理由です。

リビルドに失敗すると、おそらく、全データにアクセス不能になります。
そのなる前に、出来る限りの見えるデータを取り出すのが、最善手です。

次に2です。
リビルドの前に、全ドライブが動いているのかどうか、その確認です。
もし動いていないドライブが一台でも存在した場合は、
リビルドの前に、その動いていないドライブを正常なものに交換いたします。
なぜなら、ドライブが欠落した状況でリビルドして成功したとしても、
当然ながら「欠落のまま」になります。
そして、経年劣化したドライブで構成されたまま欠落状態が続いてしまい、
ドライブへの負担も大きくなります。近いうち、また壊れるのは明らかです。
それゆえに、整合性をすべて書き出せる新しいドライブを準備しておくべきです。

ちなみに最良な方法は、バックアップを別に持つことです。
その場合はすべて新品に入れ替えてイニシャライズし、
バックアップからデータを移転するだけで済みます。

復旧日誌3 [HDD/SSD/RAID] 暗号について

いつもお世話になっております。
本日は、暗号についてです。

暗号には二種類、存在する点に注意が必要です。
一つ目は、お互いに共通の鍵を持つ場合です。
二つ目は、暗号化で送っていただくための鍵を用意して相手に渡す場合です。

一つ目は、いわゆる合い言葉みたいなものです。
互いに知っている鍵の内容から、復号して読み書きいたします。
そのため、鍵を持つ者以外に情報を知られることはありません。

しかし、それだと不特定の方と暗号でやり取りすることができません。
そこで二つ目となります。
暗号化して送っていただくための専用の鍵「公開鍵」を相手に渡して、
それで暗号化していただき、情報を受け取るという方法です。
公開鍵は公開できるため、不特定多数から「自分」に、
情報を暗号化してから渡すことができます。

ところで、インターネットのブラウザで「暗号化されています」と表示されると、安心して個人情報を送ってしまいがちです。
しかし、ここに落とし穴があります。
インターネットは不特定多数となりますので、二つ目の方法が使われます。
そして、公開鍵がサーバから渡され、それで通信しているという仕組みです。

たしかに、通信内容は暗号化されています。
しかし、情報を受け取ったサーバ(管理者)は、内容を復号してみることができます。
つまり「守秘的な通信ではない点」に、注意が必要です。
あくまで、受け取ったサーバは、全内容を見ることができます。
そして、間にサーバを挟んでいる場合、その内容は守秘ではないということです。

「暗号化されていますだからさ、ここでの話は内密になるのだろう」、
ではございません。そのサーバには、全情報が「平文」で残っている状態になります。
ご注意ください。

復旧日誌2 [HDD/SSD/RAID] Windowsに標準実装されている「通常のフォーマット」について

いつもお世話になっております。
ブロックチェーン開発の方、方向性がばっちり定まりましたので、
復旧日誌の方を綴っていきたいと考えております。
※ 構想を練っていた2016年後半は、かかっても二年くらいかな……とみていたのですが、ちょっとばかり、いや、かなりオーバーいたしました(^^;

今日は「通常のフォーマット」です。
ディスクの管理から領域を作成すると、オプションとして存在する、あれです。
不良セクタを検出するために、全セクタを検査するゆえ、とてもお時間を要します。

ただ……、その探し方の効率が悪く、ドライブに負担がかかります。
おそらく、Windows98/2000時代からの「名残り」ですので、
その頃のドライブに合わせたまま、同じ状態で搭載されているのかもしれません。
今の大容量ドライブやビッグセクタ、超高速SSDには「不要」なオプションです。

復旧日誌1 [HDD/SSD/RAID] [Windows]ローカルデバイス名は既に使用されています

いつもお世話になっております。
本日より、復旧方面の日誌もつづっていきたい所存です。

初日は……、「ローカルデバイス名は既に使用されています」です。

ネットワークドライブとして割り当てたドライブにアクセス不能となって、
さらには、そのネットワーク自体にも入ることができない、変わった現象です。

どのような方法でも入ることができないため、データのサーバ側(NAS)を疑いました。
しかし、サーバ側を再起動等させても、症状は変わりません。

なぜでしょうか。
どうやらネットワークに割り当てた名前が重複してアクセスできない状況に至っている場合、このような状況に遭遇するとのことです。

よって、解決策は簡単でした。
ネットワークドライブを「切断」するだけです。切断するとすぐに、
すべての接続が回復いたします。
そして、ネットワークドライブを再接続して復帰です。