Aoyamaさんとこでついに istgt (iSCSIターゲットのソフトウェア)がリリースだそうです。ということで、さっそく遊んでみました。記事を書く前にいろいろやってる途中に aoyama さんとこをのぞいてみると、なんと新しい版があがっていました。むっちゃ更新早いです(^_^)。
当初は静音PCとしてiSCSIブートに興味があったものの、その後内蔵HDDを2.5インチに交換したので特に必要はなくなったのですが、深夜アニメの録画場所をiSCSI(FreeBSDのZFS)にすれば2.5インチHDDよりもパフォーマンスは良いしHDD単価も安いしでなかなかおいしいのです。でも目下の興味はそっちよりも iSCSI をMacOSXのタイムマシーン保存先にするとどうなるのかな~? というところ。
ご存知のとおり、MacOSX10.5のタイムマシーンは最強のお手軽バックアップソリューションです。ドライブをつないでおくだけで定期的にバックアップしてくれて、いざという時にはファイル単位でリストアもインストールDVDから起動してフルリストアも可能です。ただ、ネックなのは「ドライブをつないでおく」というところ。USBなりIEEE1394なりで接続するとポートを塞いじゃうし、持ち歩くノートPCの場合には接続作業そのものが面倒なのです。少し細工すればバックアップをネットワークドライブに作成することはできるのですが、MacOSX10.5のDVDから起動した場合は直接接続されたドライブからしかリストアできないので、バックアップの価値が半減してよろしくありません。ということで iSCSI の出番。
残念ながら Vista にすら入ってるiSCSIイニシエータは10.5には含まれていません。が、globalSAN iSCSI INITIATORを使えばMacOSでもiSCSIが使えるのだそうです。ということで早速動かしてみた結果。
Targetが表示されません(T^T)
あり? ターゲットを手入力しても接続に失敗するようです。同じターゲットにはWindowsからは接続できますし、istgtの代わりに iscsi-target や iscsi-target-20081225-patch を使えばターゲットが表示されて接続できますので、手続きのところが微妙に異なっているのかもしれません。
さんざん前置きした挙句ダメでしたでは面白くないので、気を取り直して istgt の仮想DVD-ROM機能をWindowsから使ってみました。
いやはや、SCSIだから冷静に考えれば当たり前なのですが、こんなのもアリなのですね。他にもDLTエミュレータというのも実装されているのだとか。ちなみに我が家で仮想DVD-ROMがどう役に立つのかというと、イースオリジンのDVDをセットしなくてもゲームが起動するのです(^_^)。うちのWindowsにはroxio コピー&コンバータ3というソフトに付属していた仮想DVDソフトを入れてるのでイースのDVDイメージをマウントすること自体は前から可能だったのですが、このソフトは電源を切るとディスクがイジェクトされた状態になっちゃうので毎回ロードしなくちゃいけなかったのですね。istgtの場合は何もしなければ設定ファイルで指定したディスクがずっと入ったままになるので、イースDVD専用ドライブが簡単に作成できます。いやはやこれは便利。たぶん想定された使い方じゃないとおもいますが(^_^)。
市販の仮想CD-ROMって昔からWindowsを不安定にさせるものが多いわけで、VistaとistgtのコンビではOS標準のソフトだけで仮想CDROMが利用できるってところがポイント高いですね。
□ 関連記事
03/05 | ( aoyama ) |
あらら動かないものもありましたか。 何しろ1から書いたものなので、パッチ版とは互換性はまったくないですね(汗) 当方の環境にはMacがないのでちょっと検証できないのですが、 もしよろしければログをとって頂けないでしょうか? rc.dスクリプトではなく直接 istgt -D -t all で起動すると 全トレースログが標準エラー出力に出ます。 新リリースを行ったので20090304版のログが欲しいです。 DVDは、まぁそんな事も想定内ですよ。 単体の出し入れは既存のistgtcontrolで可能ですが、 複数のメディア管理機能がまだないのでちょっと使いづらいです。 ISOをサーバに集約しておいて必要なときに選択して取り出す! もちろんサーバはZFSで冗長化されているので破損する危険も少ない。 みたいな事をやりたいです。 >OS標準のソフトだけで仮想CDROMが利用できる これはとても重要な事だと思っています。 DLTもWindows2000の標準ドライバで駆動できるように調整してあります。 | |
03/05 | ( たかたに ) |
お言葉に甘えまして、こんどログをとって送らせていただきますねー。 にしてもイースのDVDが想定内だったとは・・・(笑) |
最近使ってないので気づくのが遅れたのですが、うちのFreeBSDでずいぶん長いこと gnuplot が動かない状況でした。
% gnuplot
/libexec/ld-elf.so.1: /lib/libreadline.so.5: unsupported file layout
portupgrade -fR したり 一度消してから make install したり、 make world してみたりとさまざまな手を尽くしたのですが動いてくれません。ldd gnuplot で見ると libreadline.so.5 が見つからないと表示されます。見つからないファイルのファイルレイアウトがサポートされていないとはこれいかに?? といまいちよく判らなかったのですが、結局のところ
/lib/libreadline.so.5 を削除するとOK
でした(苦笑)。このファイルは x86版FreeBSDから x64版FreeBSDに上書きアップグレードした結果取り残された残骸だったのですが、まさか新規にコンパイルしたバイナリが残骸を参照するとは思いもよりませんでした。通常のアップグレードと違ってアーキテクチャを変更した場合は古いライブラリを残すメリットは無いと思われるので、再び同様の問題がおきないよう make delete-old-libs しました。
昨日 岐阜県に行ってきたのですが、くるまを買ってから初めてタイヤチェーンなるものを付けました。
いやはや、これまでは道中には雪なんてぜんぜん無くてノーマルタイヤでも問題ないぐらいだったのですが。さすがに今回は走ってる時にずいぶん雪が降ってたし、雪が積もってる道路ではスタッドレスタイヤでは動けなくなりました(^_^)。
あと関係ないのですが、私の靴がこんなんになってしまいました。
中からコンニチハしてます。お昼ご飯を食べてから歩いていたらいつの間にかこんな無残な姿に(T^T)。むかーしに買ってからずいぶん長いこと寝かせていたのですが、普通の靴といっしょで置いとくとダメになるのかもしれませんね。
02/23 | ( 通りすがりさん ) |
えらいまた見事な破砕ブーツ…。 滑ってる最中じゃなくて良かったっすね、マジで。 スタッドレスタイヤと同じく、固くなったら買い換えてね。 | |
02/24 | ( たかたに ) |
いやはや滑ってる最中だったら片足で降りてこなくちゃいけなかったわけで、歩いてる時に壊れたのは考えようによってはラッキーだったのかもですね(T^T)。 |
ギガビットなサーバーアダプタを買った・・・けれど元々のPCがあんまり良くないので速度はあんまりでません。ZFSを使ってるけどメモリも512MBしかありません。DDR1なシステムなので上限は高くないしそもそもDDR2に比べるとモジュール価格が高価です。ところで、我が家にはDDR2メモリとかCeleron420とかが余ってるのだから、安いベアボーンキットを買ってくればそれなりに動くのでは? ってことで調達してみました。Shuttle K45 ¥10,687也。いやはや、HDD/CPU/メモリが無いとは言え、マザーボード・電源・ケースが付いたセットがこの値段で買えるのですね。びっくりです。
さて、このケースは前面パネルがアクリル板になっており、ここに女の子画を挟んで「痛PC」にするのが習わしなんだそうです。まぁそうやって遊ぶのも悪くないのですが、せっかくリモートバックアップに使えるようにこないだ買ったPCIカードが刺さるものを選んだのだから、FreeBSDを入れてWOL起動させてみました。
起動しません
ぬな、これはなんということでしょう。それならばと オンボードのLAN(Marvel)がmsk0で認識されているのでこちらのMACアドレスにマジックパケットを投げてみました。
やっぱり起動しません
がびーん。旧PCと比べるとだいぶ速いのですが、電源を入れることが出来なければバックアップもできません(笑)。ちなみに、FreeBSDではなくWindowsを入れてみた場合、ドライバの詳細設定みたいなところで電源OFFからWOL起動するみたいな選択肢があって、実際に電源OFFからWOLで起動させることができます。intelでもMarvelでも可能でした。FreeBSDのドライバはWOLに対応しているのかしていないのかよく判らないのですが、ifconfig の表示では WOL とか出てきませんし、'ifconfig em0 wol_magic' とかやってみてもWOLはききませんから、何かしら手を加えないといけないのでしょう。
で、ショックのあまり一週間ぐらいほったらかしにしていたのですが(^_^)、さっき旧バックアップ機(つまり今使ってるやつ)で実験してみたところ、
ということがわかりました。WOLで起動しないのは「ドライバで謎の呪文を唱えていないから」だと思っていたのですが、そうではなくて「WOLを無効にする呪文を唱えているから」なのかもしれませんね。上記はインテルのサーバアダプタの話で、Marvelのほうは一度主電源を切るとLANのランプは消灯したままになるので話が違うと思いますが、intelのやつはデバイスドライバの初期化部分を順番に削っていけばひょっこり動くようになるのかもしれません(^_^)。
少し前のことになるのですが、intel PRO/1000 XT サーバーアダプタというのを買いました。サーバーアダプタだけどそんなに高くなくて¥4,970也。
買った理由はネットワークストレージで遊びたいから・・・というのもあるけど今回はそうじゃなくて、FreeBSDのネットワークバックアップに使ってたDELL GX260がデカくてじゃまなので省スペース型のPCに置き換えたのだけれど、そのPCのLANは100Mbps止まりで残念だったので買ってみた次第です。PCの性能はPentium4 - 2.66MHzなので100Mビットとギガビットの差はそう大きくないのですけどね(^_^)。せっかくギガビットのHUBの口が余ってるのだから差し込んでみようよ、ということです。
ところでこのPCI、カードエッジがやたらめったら長いです。調べてみると、このPCIカードは32bitの他に 64bit、加えて33MHz以外に PCI-X の133MHzでも使えるのだそうです。64bit-133Mhzの時には最大転送速度は1066Mバイト/秒になるのだそうな。これだけあればギガビットイーサなど楽々ですね。
ただ、あたりまえなのですが、うちの省スペース機には64ビットなPCIの性能を引きだすようにはなっておらず、端子が余ります(^_^)。PCIというのは64bit対応カードを32bitスロットに差し込んでも問題ないように設計されているらしいので、なんかもったいない気もしますが32bit-33MHzなNICとして使用することにします。この場合バスの帯域は133MB/秒です。ぎりぎりかもです(^_^)。
ところで、このイーサネットカードを使ってバックアップ用FreeBSDに仕立てるのはずいぶん苦労しました。というのもWOLで起動しないのです。インテルのサーバアダプタは(デスクトップでもOKなのかな?)DOSで動くユーティリティを使えばWOLを有効にできます。このアダプタの場合は IBAUTIL.EXE というのを使えばWOLを有効にできます。確かにDOSユーティリティを使ったあとシャットダウンすれば次回 WOL で起動できます。が、そうして起動した FreeBSD を halt -p でシャットダウンした後は同じようにマジックパケットを送っても起きてくれません。これでは使えません。
苦肉の策として、オンボードのLANはWOLが使えるので「オンボードとPCIのNIC両方を同じHUBに差して起動時にはオンボードのMACアドレスにマジックパケットを投げる」という方法にしてみました。FreeBSDが起動した後は ifconfig で PCIのNICだけIPアドレスを割り当ててるので実使用では問題ないのですが、こんなヘンテコな接続方法をしたのは初めてです(^_^)。
USBって便利ですよね。以前はハードディスクというとSCSIなりATAとして接続するのが当たり前でしたが、最近はUSBに変換してPCに接続するといろいろ便利に使えます。特にあらかじめUSBで外付けHDDを接続してHDDイメージをコピー、最後にPCを分解して物理的に交換 というのが最近の私のHDDリプレース手順。だから裸のドライブを接続してUSBに変換するアダプタは手放せません。
が、なんか動作が妙に感じることが稀にあるんですよね。以前ZFSプールを作成してミラーした時も妙なエラーがカウントされました。昨日は所用にてUSBアダプタのHDDにFreeBSDを入れたところ、 make world できない(コンパイルエラーが出る)現象が発生。
何かがおかしいことは間違いなさそうなので、簡単なスクリプトで実験してみました。
#!/bin/sh
base=testdata
dd if=/dev/random bs=200k count=10 | hd >$base
# ファイル作成
count=1
until [ $count -eq 1000 ];
do
cp $base ${base}$count
count=`expr $count + 1`
done
# ファイル比較
count=1
until [ $count -eq 1000 ];
do
diff $base ${base}$count
rm ${base}$count
count=`expr $count + 1`
done
rm $base
動作としては、10MBぐらいの大きいテキストファイルを作成した後 ファイル名を変えて1000個コピー、コピーが終わった後で diff にて元のファイルと同じかどうか調べています。正しく動作していれば dd が出力するメッセージ以外は画面に表示されないはずです。が、
1回目 | 2回目 |
なんと、違いが検出されてしまいます(T^T)
ちなみにおうちには2種類のUSB-HDDアダプタがあるのですが、片方は上記のように複数回実験しても違いが検出されるのですが、もう片方は試した限りでは同じHDDを使用しているにも関わらずdiffによる違いは見つかりませんでした。make world もちゃんと通ります。今まではっきりとは分からなかったのですが、USBアダプタのうち一つはダメダメだったのですねー。もしかしたらWindowsとかで使う限りは問題が起きないのかもしれませんが、FreeBSDで問題があるなら私にとってはゴミです。ゴミはゴミ箱へ(^_^)。
しかし、ハードディスクの読み書きがおかしい時はもっと盛大に(少なくともセクタ単位で)異常が見られるものだと思っていたのですが、こんな風に合計10GB弱読み書きして数バイトだけ違うなんてこともあり得るのですな。そりゃ今まで問題が発覚しなかったわけです。
オープニングの歌で知らない人が出ていたので「誰かな~?」と不思議に思っていたのですが、ようやくお出ましです。お名前はヒトミだそうです。ハルカやマキともお知り合いのようで、話の流れからいくと2代目番長でしょうか?
話し方もなんだか番長っぽいですね。
そして目を見るだけで何を考えているのか完璧に読み取ってしまう鋭い洞察力。
いやはや、ふつう目を見ただけでそんなことわかんないよ(^_^)。スゴいよ、このひと。
ただ、トウマのように男っぽいのを心がけてる様子はなくて、お弁当にタコさんウインナーを入れて持ってきてたり、愛用の傘はピンクピンクのうさちゃん柄だったりするようです。
そしてナツキとの会話。
「アタシにそんな大人な感じとか求められても。そんな目されても。ダメらから~」(スタタタ)
なんかとんでもないのが出てきましたな(^_^)。いやはや、いいなーこのひと。大好き。
FreeBSD7.1になったのが良かったのか、amd64+メモリ増量が効いたのか、以前再起動を繰り返していたうちのZFSもすこぶる安定して動作しております。ということで、UFSの時は dump で作っていたバックアップも ZFSなり の流儀で再構築です。
ZFSのバックアップはとても簡単です。ある時点でのファイルシステムを後から参照できるように置いておくには
# zfs snapshot -r tank@`date '+%Y%m%d-%H%M'`
でOK。たった一行です(笑)。たとえばこれを cron で一時間ごとに回せば MacOS のタイムマシーンのごとく過去を振り返ることができます。もっとも、バックアップは同一ディスク上に作られるわけですからバックアップにはならないという意見もあるでしょうが、
# rm -r /とか
% rm *>o
のような不測の事態(笑)には絶大な効果を発揮するはずです。
作成したバックアップ(スナップショット)は ファイルシステムがマウントされているディレクトリ下の .zfs/snapshot/スナップショット名 にて参照できます。たとえば "/usr/src/.zfs/snapshot/090114-1130" という感じ。FreeBSD-STABLEで csup したのは良いけれどいったいどこが変わったのだろう? という時には
diff -ur /usr/src/.zfs/snapshot/090114-1130 /usr/src/ | less
てな感じで変更箇所を見ることができます。いやはや便利ですね。ただ、こんな感じで参照するとスナップショットがマウントされてしまうので、dfやmountで表示されてしまいます。tcshなんかで ls /usr/src/.zfs/snapshot と打ったあと一覧を見るために ^d を押したりすると、すべてのスナップショットがマウントされてしまうのでもう大変(^_^)。
何か良い方法があるのかもしれませんが、よくわかんないのでとりあえず下のようなシェルスクリプトでスナップショットを umount しています。
#!/bin/sh
# スナップショットを umount する
snapshot=`mount -t zfs | grep "@" | awk '{print $3}'`
for i in $snapshot
do
umount -v $i
done
で、スナップショットを1時間ごとに作っていると数が際限なく増えていくので、適当に消すスクリプト。当日のスナップショット以外について、1日に1個だけいちばん古いものを残してあとは消します。当日の判断は単純に日付の桁しか見ていないので、動かす時刻は23時ぐらいでないと期待通りに動作しません(笑)。
#!/bin/sh
# スナップショットを1日1個にする
DATE=`date '+%Y%m%d-'`
FS=`zfs list -t filesystem,volume -o name -H -r tank`
for i in $FS
do
list=`zfs list -t snapshot -Ho name | egrep "$i@[0-9]{8}-[0-9]{4}" | grep -v "$i@$DATE"`
prev="hoge"
for j in $list
do
if [ "$prev" != "${j%-*}" ]; then
echo "remain $j"
prev="${j%-*}"
else
echo "delete $j"
zfs destroy $j
fi
done
done
で、最後にこっちは本当のバックアップ。ZFSで同名のプールを持ったホスト(rootでパスフレーズ無しでsshログインできる必要がある)にスナップショットを全部 zfs send~receive します。ちょっと長いので別ファイルで。実際には前後に Wake On Lan とリモートシャットダウンの処理が入っています。
リモートホストに zfs send でバックアップ
→rmtbackup.sh
UFSでは軽く1時間はかかっていたフルダンプですが、ZFSの差分バックアップなら途中のスナップショットが多くても数分で終ります。しかもスナップショットにより極めて参照が容易な世代バックアップが実現できます。(ハノイの塔アルゴリズムでdumpされたデータから特定日時のファイルを取り出すなんて考えただけでぞっとします ^_^)
ZFSは今のところ試験段階の実装なのでFreeBSDのインストーラでは扱えないなど導入に関しては敷居が高いのですが、いざ使い始めるとホントに運用は楽ちんです。ちゃんと動いている限り UFS にはもう戻れないです。
(おまけ)上のシェルスクリプトを作成中に悩んだことなのですが、「二つのファイルの共通行を抽出する」という処理は ruby だと
% ruby -e "print File.readlines('fileA') & File.readlines('FileB')"
てな感じで簡単にできちゃうのですな。共通行の抽出だと comm(1) で出来そうなのですが、この場合は辞書順でソートされている必要があります。上の処理は辞書順ではなくスナップショットの作成順に並んでいる必要があるのでこの方法は使えませんでした。rubyはこれまで使ったことがなかったのですが、上のようなエレガントな記述ができるのは魅力的です。タイムマシーンのように古いスナップショットを残容量にあわせて消していく処理はシェルスクリプトだけでは無理(結局 awk なり grep なりを何度も呼び出さなくちゃいけない)なので、ぜんぶ ruby で書いてしまえばすっきりするかもですね。その前に ruby についてお勉強しなくちゃいけませんが(^_^)。
うちのサーバーは FreeBSD 7-STABLE を使っているのですが、さっき csup してみたところ、UPDATING にこのように記載されていました。
20090207:
ZFS users on amd64 machines with 4GB or more of RAM should reevaluate their need for setting vm.kmem_size_max and vm.kmem_size manually. In fact, after recent changes to the kernel, the default value of vm.kmem_size is larger than the suggested manual setting in most ZFS/FreeBSD tuning guides.
翻訳すると「4GBオーバーなamd64でZFSを使ってる人はvm.kem_sizeを見直したほうがいいですよー。ぶっちゃけデフォルト値のほうが大きいかもですよー」という感じでしょうか。うちのサーバーはアホみたいにメモリ8GBも積んでるのでvm.kmem_sizeを1GBも確保しています。元々のデフォルトは数百MBだったかな? さて、新しい kernel ではデフォルト値がどれくらいになってるのでしょうか。
vm.kmem_size_scale: 3 vm.kmem_size_max: 1073741824 vm.kmem_size_min: 0 vm.kmem_size: 1073741824 |
vm.kmem_size_scale: 3 vm.kmem_size_max: 3865468109 vm.kmem_size_min: 0 vm.kmem_size: 2726834176 |
旧kernel(/boot/loader.confで値指定) | 新kernel(デフォルト値) |
おわ!! 2.5GBぐらいになってますな。いくらなんでも1GBよりも大きくならないだろうと思ってましたが、それの2.5倍になっちゃったとは(笑)。でもこれくらい大きく取れば何をしてもpanicしないだろうから安全で良いでしょうね。ちなみに、この値を大きくしたからといって即 空きメモリが小さくなる訳ではないようで、topで見ると相変わらず5GBほど空いてます。もしかしたらサーバーのメモリは4GBでも大丈夫なのかもしれません(T^T)。
02/09 | ( 通りすがりさん ) |
私もあまり詳しくはないのですが、kmemはメモリ空間のうちアプリケーションに渡さない領域だから8GB中2.5GBならば残りの5.5GBがアプリケーションで利用できるはず。 そしてファイルサーバ専用機ならば5.5GBもいらないのは言うまでもないw そもそもZFSがメモリ要求した時にカーネルがメモリないですって応答するとだだをこねる(ぉぃ)のが原因なので、ARC (Adaptive Replacement Cache)を制限しちゃうと性能はでないけどメモリを使わなくなる。 なので逆にARCを増やせばkmemも消費されるのでは? あとZFSがメモリを消費するのは巨大なファイルを連続でアクセスする時のようです。 vfs.zfs.arc_max="512M" ↑/boot/loader.confにこういう設定です。 手元にテスト可能なamd64のZFSがないのでそちらはよくわかりませんが、kmem_sizeを限界まで大きくしてarc_maxも増やせば消費されるかも? | |
02/09 | ( たかたに ) |
これまたいろいろありがとうございます。ふむふむ、 vfs.zfs.arc_max でキャッシュを制御できたりするのですね。てことでうちの値を見てみました。 # sysctl -a vfs.zfs.arc_max vfs.zfs.arc_max: 2045125632 あわわわ、値をいじる前から2GB弱あります(笑)。数字を大きくすればメモリ使用量は上昇するかもしれないけれど、それでパフォーマンスが向上するとは考え難いですね(^_^)。 ちなみにうちのサーバは自分によるアクセス数がいちばん多いWWWサーバ(^^)なのでZFSを使わなければメモリは512MBで十分かもしれません(苦笑)。 |
なんと新しい Google Earth では
ん? なにやら中央に360の表記がありますね? これはナニかな? と思って押してみました。
「このレイヤを表示」を押してみると
360が増殖します。で、この360の一つを押してみました。
なんと、Google Earth でストリートビューを表示させたときのごとく、トップビューから球体の写真の中に入って360°ぐるぐる見渡せるようになります。よよよ、これは面白い!! ストリートビューと違って人物の顔までくっきりです(笑)。
姫屋を見てみようかと思ったのですが、残念ながらストリートビューほど多数の撮影ポイントが無いので正面からはとらえられませんでした。アリアカンパニーの場所もよくわかんないのですが、サンマルコ広場は結構たくさんデータがあるようです。ということで、ターゲットはもみ子の気になる御方!!
馬のケツから左に行って海が見える方角なのでこの場所のはずなのですが・・・。
拡大するとこんな感じ。う~む、ホントにこれかな? 違うかな? ちょっとこの画像では判断が難しいですな。
ともあれ、詳細画像をぐるぐる回せるのは面白いです。iPod touch でもぐるぐる回せるアプリ があったのですが、ひょっとしたら同じデータなのかもしれませんね。
# ブラウザで表示させるとこんな感じになるようです02/06 | ( Y.Kumagai ) |
かつての公開死刑場に上半身のない人影が2つ…怖っ!!(笑) | |
02/07 | ( たかたに ) |
二つ!? 中腰の人とぐるぐる渦巻きの人かな? 他の部分が違和感なくつながってるのだけに足しかないのが笑えますね。あ、いや、恐いんでしたね(^_^) |
安物ノートPCのキーボードはとっても出来がよろしいのです。そのできばえは大げさに言うと MacBookPro に匹敵するほど。だから入力していると MacBookProで入力しているのと勘違いして入力ミスが頻発するんです(T^T)。
最近まで知らなかったのですが、イマドキのIMEは OFF の状態から CapsLock キーを押すと 日本語モードがON になっちゃうのですな。コントロールキーのところに CapsLock があるもんだからつい押しちゃって、しかもそのたびに日本語入力モードになっちゃうのだから使いにくいったらありゃしない。いや、ThinkPadやお絵かき機のキーボードではこんな間違いはしないのですが、中途半端にMacBookProに色やタッチが似ているので間違えちゃうのです。
CapsLockなんかいらないからCTRLキーにならないのかな? と思って調べてみたらそういう方法もあるのだそうで、下記をレジストリエディタで書き込めばCapsLockキーがCTRLキーになります(CTRLキーはそのまま)。再起動するか一旦ログアウトすれば有効になるようです。
Windows Registry Editor Version 5.00
; (1) CapsLock をCTRLキーにする
[HKEY_CURRENT_USER\KeyBoard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,1d,00,3a,00,00,00,00,00
中身は8バイトのヘッダに続いて 02 00 00 00 の long word 値が終端を含めた入れ替えの個数。後は1d 00(CTRL)←3a 00(CapsLock)の順で上書きするスキャンコードを並べます。入れ替える場合は順序を変えて両方書けばOK。で、最後に終端の 00 00 00 00。
これは便利。変なソフトが常駐するわけじゃないので動作が不安定になることもないだろうし、CapsLockなんかたぶん一生使わないし(^_^)。これでMacBookProのつもりでCTRLキーの場所に指を伸ばしても誤動作することがなくなりました。
気をよくしてお絵かき機でもちょっとした設定をしてみました。
Windows Registry Editor Version 5.00
; (2) 左Windowsキー無効
[HKEY_CURRENT_USER\KeyBoard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,00,00,5b,e0,00,00,00,00
これまた一生使わないミ田キーが109キーボードには付いてて困っていました。Painterではなげなわツールで領域追加とか削除とかにCTRL,ALTをよく押します。基本的に手探りで押すので2つのキーの間にエラそうに頓挫するミ田キーを時々押しちゃって困ってたのです。でも もう大丈夫。上の呪文を唱えればミ田キーを押しても反応無くなりました。もっと早くにやっとけば良かったですー(T^T)。
# だけど、CTRLキーがAの隣に来ちゃうと 今度は日本語入力に切り替えるときに[変換]キーを押しちゃって困るという新たな問題が浮上(笑)漫画原稿用紙とかインクとかは小さい文房具屋さんに行っても置いてないし、Amazonにあったらいいのにな~と思っていたのですが、本日見てみると取り扱ってました。
漫画原稿用紙 A4 110g
http://www.amazon.co.jp/dp/B000UG9JTM
インク アイシーコミックスーパーブラック
http://www.amazon.co.jp/dp/B000UG2G9M
これを書いてる時点では漫画原稿用紙が¥578、インクが¥525。たぶんToolsで買うよりも高いのですが、会社の帰りにToolsに寄るのはずいぶん遠回りになるので、10~20円高いぐらいなら Amazon で買えると便利だなーと思います。
ところで、最近私の使ってるインクはパイロットのやつばっかり。手元に Dr.Martin's BLACK STAR があったので試し書きしてみましたが、伸びは良いけど線が太くなる気がします。昔書いたメモを見てみるとアイシーのやつも同じ特性らしいのですけど今使ったらどうなのだろう? 手持ちのインクがなくなるころには Amazon でもパイロットを取り揃えておいてほしいかな。