Retrospect

ああ^^;

少なくとも,オーストラリア赴任の時には使っていましたから,Retrospectとのつきあいは20年ほどになります.

OS X版になってから遅いのなんのって^^; で,新しいバージョンが出る度に,何十パーセント速くなったっていう売り文句なんですが,全く速度の向上が体感できません.

たかだか数GBの更新されたファイルの吸い上げは10〜30分で終わるんですが,そのあと,”Building Snapshot”という表示が出てからが長いです.で,どういう条件だと時間が長くかかるか(あるいは,短くできるのか)が全く不明で,一番長いクライアントは24時間くらいかかります.

最近のRetrospectのバージョンではRetrospect Instant Scan Advancedという新機能が含まれています.これは,クライアントのマシンでRetroISAというデーモンが動いて,事前にRetrospectに都合の良いカタログを作っておくようです.

ところが,私が個人用に使っているRetrospectはVersion 9とかで,クライアントがこのRetroISAでカタログを作ってもその恩恵には与れませんから,ただCPUサイクルを無駄に消費することになります(SSDの寿命も多少は縮めるでしょう).

ということで,それを止めたい場合は,

sudo launchctl unload /Library/LaunchDaemons/com.retrospect.retroisa.plist
sudo defaults write /Library/LaunchDaemons/com.retrospect.retroisa Disabled -bool true

(下記参照ページより)という,コマンドを実行しますが,クライアントのコントロールパネルにON/OFFのスイッチを付けないというところが,なんとも,馬鹿にしてますよね^^;

実は前週末,家族用のMac miniのSSDの内容が完全にぶっ壊れて,復旧作業をしたのですが,Retrospectは全く出番がありませんでした.

とにかく,一つの行程が30分から数時間かかることがざらなんです.たとえば,リストアするのに,保存されているディスクの内容を開こうとすると,そこで,何十分,選んで,何かの準備をするとまた何十分,最終確認で,違ったかなと思ってやり直すと,また何十分ずつを繰り返します.”Cancel”を押しても待たされることがあります^^;

結局Time Machine機能で,Time Capsuleから復活させました.こちらも,一晩かかりますが,設定は,たいして時間のかからない簡単な手順なので,すんなりと”実行”ボタンを押して,あとは寝て待てば良いだけです.

しかし,しかしなんですが,Linuxのバックアップは,Retrospectしかないんですよね^^; ということで,Linux用に残して使っている.それなら,ついでに,ということでWindowsもMacもバックアップしておく,という考えで,ずるずる引きずっています^^;

Macだけならば,Time Capsuleと外付けディスクで二重にTime Machineでバックアップするなどしておけば,十分だと思います.

自分宛のメモ

“Retrospectはついでにバックアップを取っているだけなので,復旧はTime Machineからすること”

参照ページ

Appearanceを変えてみました

当サイトのappearance(スキン)を変えてみました.

WordPress用にはそれこそ無数のappearanceが用意されていますが、なかなかこれというものがありません。自分としては、スマホ対応で、かつ、PCで見てもスマートなものが希望なんですが。

Bitdefender

Virusとの遭遇頻度を考慮すると,Macの場合は,週に1度virusのスキャンをかけておけば十分とのことです.

ということで,その用途にかなったBitdefenderの無料版を使い,気がついたら手動でスキャンの起動をしています.たいてい数日から10日くらいでかけています.

職場のICT関係のアウトソーシング先が,大手G社からM社に変更になり,いろいろ設定をしたりしているついでに,仕事用のMacProの保存データの棚卸し的なことをしてます.

SSD 1TBのうち,既に600GB越えのデータが詰まってして,要らないデータの削除をしてます.

いろいろ調べたところ,~/Library/Containersというところが30GBも占めています.そのほとんどをcom.bitdefender.BitdefenderVirusScanner というディレクトリーが占めています.

ここを削除することで,Bitdefenderがいったん初期化されて,多少の不便はありますが,30GBもの容量が解放されるのは悪くないことです.

SSDの寿命

SSDには,書き込み回数による寿命があることは知られています.では,今売られているSSDの寿命はどのくらいなのかを,The Tech Reportというサイトが,継続的に取り組んで,報告してくれています.

その結論的な記事が下のリンクです.

一番早くだめになったSSDでも700TB書き込めて,標準的には1PB書き込めるという結論です.

テストでは,240GB前後の容量のSSDを使っています.SSDは,書き込むブロックを分散させるようにできていますから,1TBのHDDの場合,理想的には4PBまで書き込める可能性があります.

で,iostatで,自分の管理するLinux WSを見てみると,1日あたりの書き込みは1〜4GBです.まぁ,ディスクイメージをまるまるコピーするような作業をときどき行うなどして,1日の平均を多めに20GBと見積もって,寿命が1PBならば,137年,4PBまでOKなら,548年と言うことになります^^;

もう一つのSSDの優れた点は,エラーが出て使えなくなるまで,読み書きともスピードの低下がほとんどないことです.

スピードや容量が大幅に改善されたものが出てこない限り,交換不要の一生もんといえそうです.それよりも,経年変化でどこかの部品が先に壊れますね.

64bit化まとめ

なんとか,Slackware 64の自分ナイズについて,全体が見えたので,いったんまとめておきます.

Kernelのbuild

Kernelについては,当初,自分でbuildしたkernel (3.19.0, 3.19.1)がモジュールを自動的にロードしないので困っていましたが,Slackware 64付属の.configを使うことで,解消しました.たぶん,force loadingとかいうオプションがONになることで解消したと思いますが,動けば良いので深くは追求してません.

Slackware 64付属の.configを使うことによる副作用は,ほとんどのモジュールをbuildしてしまうことですが,これも,たいした問題ではないので,放置します^^;

また,kernel のmakeで,build済みのオブジェクトも毎回コンパイルし直すようです.これも,大きな問題ではありません.

まだ,initrdを使う起動はうまくいっていません.が,それも使わなきゃ良いんです^^;;

ソフトのメンテナンス性

ほとんど,Slackware (32bit)と変わりません.Slackwareに付いているソフトについては,SlackBuildでbuildできますし,含まれていないものも,通常のconfigureオプションでたいていbuildできます.

KVM/QEMU

これが,最大の壁でした.いくつかの関連パッケージは,32bitよりもサクッとbuild & installできましたが,最後のvirt-managerがうまくいかず,あきらめました.

手動で,qemu-system_x86_64は起動するのに,virt-managerでは,使用できるエミュレーターがないというメッセージを出してお手上げです.

関連ソフトは,何巡かbuild & installしています.

使わないことに

多少の制約は残っても後々の問題として抱えたまま,できれば64bitに移行したかったのですが,今日では必須となってしまったKVM/QEMU環境が構築できなかったので,Slackware 64への切り替えは見送ることにしました.

もちろん,最初からKVM/QEMUが含まれている64bit distroを使えば良いだけのことなんですが,それじゃぁおもしろくないです.これまで蓄積してきたSlackwareによるserver/routerの運営ノウハウが活かせません.

というか,Slackwareが好きなんでしょうがない^^;