start

Firefoxのリセットは内蔵の「Firefoxをリフレッシュ」が便利

動作が重くなったFirefoxを復活させる手立てとして、Firefoxのキャッシュや履歴の削除という手段が良く用いられる。ちょっと探せばその為のアドオンや解説ページはゴマンと出てくるが、いつ頃からかFirefox自体にリフレッシュ機能が実装されたようだ。

メニューの``[ヘルプ]>[トラブルシューティング情報]``を選択、もしくはアドレスバーに``about:support``と入れて開くと「トラブルシューティング情報」ページが開き、右上にある「Firefoxをリフレッシュ」ボタンを押すと掃除が行われる。

この機能の何が便利って、ブックマークや保存したパスワード、Cookie、開いているタブ情報などは残したまま、拡張機能やツールバーなどのデータだけを消してくれる。で、掃除前のプロファイルはOld Firefox Dataとしてデスクトップに保存されるので、もしリフレッシュ後の状態に支障があればリフレッシュ前に戻すことも可能。素晴らしい。

実際に、プチフリやらAjaxのセッション切れ?が頻発しFirefoxを再起動するまでサービスが使えなくなる状態のFirefoxをリフレッシュしてみたところ、見事に問題が解消された。素晴らしすぎる。

前述の通り、拡張機能とその設定が全てなくなるので、拡張しまくってる人には辛いかもしれないが、リフレッシュを気にアドオンの見直しを行うってのも一興ではなかろうか。Firefoxが重くなる原因は大抵アドオンにあるわけだし。ちなみに、自分はもうツリー型タブとμBlock Originしか入れてない。

良きFirefoxライフを!

Firefoxの消えてしまった「以前のセッションを復元」を復元

転ばぬ先の杖というわけで、大変素晴らしいアドオンTab Session Managerを入れておきましょう。

Firefoxの再起動時、何かの弾みでタブのセッション情報が消失し「以前のセッションを復元」が使えなくなることがある。ブックマーク前の有益なサイトを開いてたりすると、さぁ大変だ。

どうにか復元出来ないものかと悪あがきしてたら、以下の方法でセッションを復元出来るようだ。

  1. 現在のプロファイルフォルダを開く
    • メニューの [ヘルプ]>[トラブルシューティング情報] の「プロファイルフォルダ」から開くのが簡単&確実。
      • 以下、プロファイルフォルダをmyprofile.defaultとする
  2. Firefoxを完全に終了する(メニューから終了させるのが確実)。
  3. myprofile.default/sessionstore-backups フォルダの中から“それっぽい”セッション情報ファイルを探す。ファイルはJSONなので普通にテキストファイルで開ける。
    • ここで見つからなければ試合終了なので素直に諦めて下さい。
  4. 見つけたファイルをmyprofile.defaultフォルダにコピーし、sessionstore.jsにリネーム。
    • このファイルが「以前のセッションを復元」で使われている模様。すでに存在してたら上書きでおk。
  5. Firefoxを起動すると「以前のセッションを復元」が使えるようになっているハズ。

いやしかし、このセッション情報を壊したくないからプロファイル切り替えたってのに、いつものプロファイルに戻ったら見事にクリアして下さりやがったのは、どういう了見なのMozillaさん(´・ω・`)?

MIDI音源が受け付ける初期化メッセージと挙動

サクラ質問の板で、各MIDI音源モジュールが受け付けるシステムセットアップメッセージと挙動の素晴らしいまとめを発見。 非常に有益な情報で消えた時のダメージが(個人的に)計り知れないので、保存もかねて転載させて頂きます。

No.4912/各音源が受け付ける初期化コマンド
■投稿者/ ねお -(2004/02/11(Wed) 14:24:52)
□ U R L/ http://textso.under.jp/

    ねおです。
    交流板で話題になっているので質問してみます。

    「あなたが使っている音源は、どの初期化コマンド(GM、GM2、GS、XG)を受け付けますか?」

    ●音源名
    ●受け付ける初期化コマンドと、受け付けたときの動作
     (受け付けた、ってことをあなたがどうやって判断したか)

    よろしくおねがいします。
No.4913/ねおの場合(SC-88、SC-8850)
■投稿者/ ねお -(2004/02/11(Wed) 14:30:43)
□ U R L/ http://textso.under.jp/

    ●音源名
    SC-88VL(SC-88から音色作成用パネルを省いた廉価版)

    ●受け付ける初期化コマンドと、受け付けたときの動作
    ・GMリセット → GSバリエーション音色が使えなくなる
    ・GSリセット → 本来の動作
    ・SC-88モードセット → MODE-1とMODE-2が切り替わります(MODE-2だとポート1と2で別のエフェクトが使える)

    -----------------------------------------------
    ●音源名
    SC-8850

    ●受け付ける初期化コマンドと、受け付けたときの動作
    ・GMリセット → GSバリエーション音色が使えなくなってピアノになります
    ・GM2リセット → 使ったことはありませんが説明書に書いてあるので
    ・GSリセット → 本来の動作
    ・XGリセット → ピアノ曲を再生してみたらXGっぽい音色(以前借りてたMU1000みたいな音色)に変わりました

    ※SC-88モードセットについては不明。ご存じの方教えてください
No.4920/(((n;‘Д‘))ηの場合
■投稿者/ (((n;‘Д‘))η -(2004/02/12(Thu) 02:08:01)

    88モードセットの解釈はそれで大体あっています。要するに、SC-55相当の音源を
    仮想的に2台に見せかけるモードです。
    確かSC-8850ではMODE2は非対応になったんでしたっけ?

    Roland SC-55, SC-55mkII
    ●受け付ける初期化コマンドと、受け付けたときの動作
    ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる
    ・GSリセット → 本来の動作
    ・SC-88モードセット → 認識しない
    ・XGリセット → 認識しない

    Roland SC-88Pro
    ●受け付ける初期化コマンドと、受け付けたときの動作
    ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる
    ・GSリセット → 本来の動作
    ・SC-88モードセット → モード1/2の切り替え
    ・XGリセット → ドラム音色配列がXG互換に(通常音色はBANK0のみになる?未確認)

    YAMAHA MU50/80/90/100/100B/100Bs/100R/128/500/1000/1000EX/2000EX
    YAMAHA S-YXG50系、DS-XG系、AC-XG系
    ●受け付ける初期化コマンドと、受け付けたときの動作
    ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる
    ・GSリセット → TG300Bモードに切り替わる(MU1000EX/2000EXからはGSモードと名称変更)
    ・SC-88モードセット → 認識しない
    ・XGリセット → 本来の動作

    TG300BモードはGSモードと同等です。SC-88以降のディレイやMFXには対応しません。
    TG300Bの音色数は基本的にSC-55相当です。
    しかし、後期に販売されたMUは音色数が微妙に増えています。
    実際にどの音色が追加されたかまでは調べていません。自分でマニュアル見てください。
    (尤もTG300Bモードは互換性の為に用意されているので、このモードで曲を作る意味合いは全くありません)

     NS5R/NX5R
    ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる
    ・GSリセット → 音色配列がGSと互換性の高い物に変わる、エクスクルーシブはSC-55相当の物を一部受け付ける
    ・SC-88モードセット → 認識しない
    ・XGリセット → 音色配列がXGと互換性の高い物に変わる、エクスクルーシブはXGの物を一部受け付ける(バリエーションエフェクト非対応)

     Roland SD-20/80/90
    ・GMリセット → General MIDI Level1で規定された命令しか受け付けなくなる
    ・GM2リセット → General MIDI Level2で規定された命令しか受け付けなくなる
    ・GSリセット → 音色配列がGSと互換性の高い物に変わる、エクスクルーシブはSC-55相当の物を受け付ける
    ・SC-88モードセット → 認識しない
    ・XGリセット → 音色配列がXG Liteと互換性のある物に変わる、エクスクルーシブはXG Liteの物を一部受け付ける?(バリエーションエフェクト非対応)

既存と異なる構成のvdevをプールに追加しても特に問題はないらしい

ZFSで既存プールにストレージを追加する場合、既存のvdevと同じ構成のvdevとするのが基本である。具体的に言うと、HDD 3台のRAID-ZプールにHDDを追加するには、HDD 3台を追加しなければならない。HDD 4台を追加しようとしても「mismatched replication level: pool uses 3-way raidz and new vdev uses 4-way raidz」と怒られてしまう。実際のログはこんな感じ。

$ zpool status
  pool: ztank
 state: ONLINE
  scan: none requested
config:
 
        NAME        STATE     READ WRITE CKSUM
        ztank       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da0     ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
 
errors: No known data errors
 
# zpool add ztank raidz da3 da4 da5 da6
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses 3-way raidz and new vdev uses 4-way raidz

だがしかし、ログにもある通り-fオプションを付けると、異なる構成のvdevでも難なく追加出来てしまう。

# zpool add -f ztank raidz da3 da4 da5 da6
# zpool status
  pool: ztank
 state: ONLINE
  scan: none requested
config:
 
        NAME        STATE     READ WRITE CKSUM
        ztank       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da0     ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da3     ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
 
errors: No known data errors

この通り。

forceオプションが必要な事からも分かるように、これは非推奨のプール構成である。かといって、何か問題があるかというと実は然程問題ないらしい。vdevの使われ方に偏りが出たり性能が落ちる可能性はあるものの、危険だったり有害だったりはしないそうだ。まぁ、本当に危険だったら、この操作そのものが許されてないよね。

ZFSの仕組み上、プールの特性は構成する各vdevの最も低い特性の影響を受けるので、vdevの特性は揃えておくのが望ましい事から「非推奨」となっているようだ。名前の通りvdevを仮想的な1台の物理ストレージに置き換えて考えると分かりやすいかなと。

ゆえに上記プール例では速度がHDD 3台のraidz1-0に引っ張られる事になる。また、物理HDDが全て同じ容量だとすると、raidz1-1の方が大きいので容量の消費も偏る事になるが、raidz1-0とraidz1-1はストライピングであることから総容量は全て使われる(ハズ)。ミラー構成時の容量にだけ気をつけとけば、そんなに神経質になることもないのかも。少なくとも家庭用NAS用途なら殆ど問題にならない気がする。速度面ではネットワークが最大のボトルネックだしね…。

よくよく考えると、うちのサーバはHDD×3でRAID-Zの所に空き容量低下でHDD×3を追加したもんだから、vdev間の偏りたるや相当なもの。zpool iostatで見てもストライピングというより最早JBOD状態で、こんなのでもちゃんと動いてるんだからvdevの構成違いなんて誤差みたいなものでしょう、きっと。

C#のCreateDocumentTypeがタイムアウトする時の簡易対策

C#のXmlDocumentでHTMLを生成しようと、W3CのDTDを指定してXmlDocument.CreateDocumentType()するとタイムアウトやHTTPステータスコード500で例外を吐くことがある。こちとらvalidなHTMLを生成しようと真面目に指定してんのに、この仕打である(´・ω・`)。みんなW3Cを見に行って慢性的な高負荷状態になってるのが原因らしいが、まぁ当然そうなりますわな…。

コードにすると↓な感じ。

XmlDocument doc = new XmlDocument();
XmlDocumentType docType = doc.CreateDocumentType(
	"HTML",
	"-//W3C//DTD HTML 4.01 Frameset//EN",
	"https://www.w3.org/TR/html401/frameset.dtd",
	null); /* ここでエラー */

XmlResolverでローカルキャッシュしたDTDをマッピングするのが正攻法らしいのだが、ぶっちゃけ面倒。というか、調べても良くわからんかったのでパスw(分かったら追記する…多分)

とりあえずエラーを回避するだけなら、CreateDocumentType実行前にXmlDocument.ResolvernullにしてやればOKっぽい。コードにするまでもないが一応書いておく。

XmlDocument doc = new XmlDocument();
doc.Resolver = null; // 追加
XmlDocumentType docType = doc.CreateDocumentType(
	"HTML",
	"-//W3C//DTD HTML 4.01 Frameset//EN",
	"https://www.w3.org/TR/html401/frameset.dtd",
	null); /* エラーにならない */

・・・と、ここまで書いて思ったが、これで回避できるって事は自前実装したXMLリゾルバでDTD返してやればいいだけなんじゃね?

  • start.txt
  • 最終更新: 2022-07-27 15:26
  • by Decomo