2020年5月ご依頼のご案件です。 一度、他社にて「復旧可能」と言われていたのですが、 こちらに再ご依頼いただいたケースとなります。 This is a request for May 2020. This was said by other company that it could be recovered the data. But …………… This is the case that the customer is canceled previous company, then it again requests to our company in this drive.
論理パーティションがセクタ単位上書きで破壊され、 復旧可能なデータが抜かれている状態で消滅していました。 こうなってしまうと、データの復旧は「どこにもできません」。 What is this? It’s many just like this, and we are going mad. The logical partition have been destroyed by sector-by-sector. e.g. overwrite … thus, these have been disappeared with recoverable all data removed. If this case, we … yep, all over the world of recovery company won’t be able to recover your data!!
このパターンは2005年からある、比較的よくみるパターンです。 ドライブを業者に預ける際は、十分な注意をお払いください。 This pattern is a relatively common pattern that has been around since 2005. Please be careful, when you let your the precious drive to a recovery company!!
At first, the power of the drive itself don’t turn on, so we have determined that there is an electrical system failure. However, the computer on the board of drive itself does not work at all supply to computer, and we had determined that there was something wrong with the electrical system … But, It was a cause that replacement of the firmware ROM. The ROM of completely different models have been loaded, we are convinced that this don’t work.
We are currently working on porting this blockchain to a new core.
Please wait for a while as we will adjust it to synchronize with the old core.
Drive failure predictions will be implement into this new core. In this way, even if the drive failure prediction don’t work, if the old the blockchain works, system of money transfer can be maintained.
Thank you for the great analysis. (https://www.atomminer.com/)
This time, IPV6 is enabled as standard, and the placement of CriticalSection is changed.
Next time, we will implement RPC thread pool and verify with testnet.
In order to prevent deadlocks, we would like to put a mechanism like the message queue implemented in Windows.
The RPCs that need to proceed after processing has been processed reliably are like SendMessage, and if there are no problems asynchronously by accumulating in the queue with RPCs are processed efficiently with a mechanism like PostMessage.
Also, if we consider only the PostMessage part instead of thinking about the scope of CriticalSection, it can prevent deadlock even if it is complicated.
We will fix CriticalSections that classified according to the RPC processing issued by the mining pool. ※ Ultimately, CriticalSection is expected to be narrowed down to one.
As for this processing part, FIXME was attached, and it was operating abnormally with PoMP of NOMP.
This time, YiiMP PoW had a problem, so I decided to go back to the original CriticalSection and see what it was. However, if it is this, it will not work with NOMP. Therefore, it will be divided by the macro of the compiler.
As an improvement method, I think that this RPC itself will be like this as Windows PostMessage, so that it will be issued one by one after being accumulated. ※ The current situation is similar to SendMessage that some of them do not work.
In addition, if this improvement is implemented, all RPCs will be affected, so I think that it will be released after testing with testnet.