HDDのバックアップツールは選びましょう

と言うことで、昨日からずっと試験をしていたツールに関する結果です。

どうもパーティションコピーを行うツールによってブート処理が成功する物、失敗する物があるらしい

と言うことがよく分かりました。

初めのうちはこれが分からなかったので、Linux経由でGPartedを使ってパーティションをコピーしてみたのですが、起動ができませんでした。

前にパーティションコピーを行ったときにはうまく起動できた記憶があったのですが・・・。

というわけで、いくつかバックアップツールを用意してテストをしてみました。

  1. LinuxからGPartedによるパーティションレベルのコピー(LinuxにはUbuntu(巫女GNYO)を使用)
  2. EaseUS Disk Copy(Free Edition)を使ってCD-ROMブートを行いパーティションをコピー
  3. Macrium Reflect(Free Edition)をWindowsにインストールしてパーティションをコピー

一応個人レベルで使用する分にはフリーの物です。下の二つは個人レベル以外になるとフリーではなくなるので注意。

で、HDDをセクタレベルコピーを何回か行ってブートテストをしてみたところ・・・

この三つの場合はReflect以外の方法でコピーするとつなぎ替える(HDDのSATA接続をいじってバックアップ先をブートするように配線する)とWindowsが起動できないことが判明。

Reflectの場合はバックアップ時に一部のブートレコードに関する項目も修正する、と言う項目が出ていたとおりDualBootになっているそれぞれのOSも起動できることを確認できました。

とにもかくにも確認するまでにかな~りの時間を使ってしまいました・・・。

200GBレベルのセクタコピーなので最低でも45分くらいかかってしまうのが痛いと思いました。

ちゃんと結果が確認できたのでOS領域のパーティションバックアップ(クローン)にはしばらくの間Reflectを使用することにします。

データレベルのバックアップなら普通にコピーツールを持ってきて使いやすいファイルシステムでフォーマットするのが正しい

です。Windowsを使っているならNTFSで適当に領域を確保してファイルコピー、で大丈夫ですし。

Linux系との共有であっても最近の物ならほとんどはNTFSへの書き込みもサポートされているのでバックアップ目的なら問題ありません。

たま~にGPartedで処理をしたが故にファイルシステムをext4で作成してデータをバックアップしてしまった馬鹿もいますが。

この場合の利点は

  • バックアップ用Linuxを起動させて行うので、コピー時にWindowsに無駄な処理を行わせなくて良い
  • Windows側からパーティション操作による解放処理以外では基本的に読み込む/書き込むことができないのでWindows側からのウィルス感染を防ぐことができる

というところですか。利点より欠点(Windows側からのバックアップができないのが面倒すぎる)が大きすぎますかね。

AndroidでWindows実行ファイルのエミュレーションができないかと探していたらあるのね・・・

存在していなかったらどうやって作ろうか考えてしまったかもしれません。

「Eve -Eroge’s valid equipment-」というプロジェクトだそうです。

エミュレーションの方法も簡単に解説されていますが、さすがにPC98エミュレータを作っていた方らしくx86命令をインタプリタで実行している、との説明が。

命令のエミュレーションやWin32APIのエミュレーションに関しては実装だけならがんばれないこともないですが、それを実用速度で、と言うのがすごいと思います。

一度使ってみたいところですが、さすがにXperia acroレベルでまともに動かせるとは私も思っていない(PC98Emuですら一部の動作で遅れが出ている)ので、

次に端末を交換したあたりで試してみたいと思います。

で、何となく「どうにかして(ADVゲームに限定してでも)高速化の手法がないか?」と微妙に考えたりしていました。

たとえば、この場合はexeがゲーム単体であることを利用して

  • 実行ファイルをロードした時点で一度解析を行ってx86コードを動作させやすい中間コードに変換して実行する

を考えてみましたが、これは

  • コード解析に失敗すると実行できなくなってしまう
  • エンジンがDLLをロードするタイプだと途中で再解析が必要になるのが面倒では?
  • 中間コードと言ってもARM系で高速となるような中間コードってどういう物?

となったり。

また、ゲームで実行時間をとる本質が描画であることを考えて

  • 実行ファイル中から描画ルーチン(Blt系、半透明合成)を取り出してその部分だけneonなどのARM系のSIMD命令で実行できないか?

とか言うことも考えたり。これは

  • 描画ルーチン単体を検出するのは難しすぎる。まさかADVエンジンごとに呼び出しアドレスを調べてDB化する、というのはさすがにどうかと
  • MMX実装部をneonでエミュレーションはできるが、ビット幅処理をどうやって整合させるか(MMXは64bit処理。neonは基本128bit処理でそのままエミュレーションはできるがもったいない。拡張は難しい)

とか。この手のノウハウは一度やったことはあるので無いことはない(WindowModePatchがエミューションのような形をとっているため)のですが、さすがに難しいですね。

簡単な物ならDirectX系も実装しているそうなので、さすがだと思います。


コメントを残す

メールアドレスが公開されることはありません。

*

この記事のトラックバック用URL