Orz日記 by Akio Morita

_ [雑記]Solaris10 on QEMU

SADのテスト用のSolatis10が欲しかったので、QEMU上に インストールしてみたのだが、QEMUの仮想NICを認識しない罠 Orz

_ [SAD]Hold

Mathematicaのマニュアルによれば、Holdは式を未評価のまま返すので

In[] := Hold[1 + 1]
Out[] = Hold[1 + 1]

になるのが、Mathematica的には正しい実装らしい

つまり、構文解析時に純粋関数を簡約する SADの実装は Mathematica互換では無い (「構文解析時に純粋関数を簡約する」のは、生出さんによれば仕様である)

_ [FreeBSD][Admin]ZFSへ移行

gmirror+UFS2/softupdateからZFS/mirrorへ移行した。

ざっくりとした手順

1. shutdown & gmirrorの片肺を ZFS用の diskに交換(取り外した diskは作業前のsnapshotになっている)
2. zpool createする
3. level 0の live dumpと restoreで ZFS側にデータを移す
4. gmirror側への更新を行う cron/daemonを停止
5. rsyncで UFSから ZFSへ同期
6. fstabから UFSを comment-outして umount
7. ZFSの mountpointを更新
8. gmirrorを stop/clearして zpool attachで ZFSを mirror構成へ

はまった点

dump & restoreでは ACLが移行できない

正確には、UFSの POSIX 1e ACLと ZFSの NFSv4 ACLに互換性が無いので UFS dumpに含まれる POSIX 1e ACLの情報を restoreは ZFSへ反映できない

したがって、setfaclによる手動設定が必要(NFSv4 ACLは若干書式が変わるので注意が必要)

ACLを大量に設定している場合は、restoreを hackすることを考えるか、 他の同期手段を考えるべきでしょう。(rsyncの --acls optionは試していません)

メリットは？

• 管理が簡単
  • diskとfile system管理の一体化
  • directory単位の圧縮/exec/setuid属性の設定
• CVS repositoryの updateの高速化

実は、まったく速度は期待していなかったのですが、ZFS上に移った FreeBSD ports-CURRENT repository mirrorからの cvs updateが高速化しました。

ports-CURRENTは directory entry数が多いので DIR_HASHがあるとはいえ linear searchな UFSよりも B-Treeベースな ZFSが検索が有利である点と、 memory搭載量が多いので cvsup後の状態だと主要な directory entryが L1ARC上に cacheされた状態であるのが効いているのだと思います。

_ [SAD][EPICS]CaRead1/CaRead2インターフェース仕様

コード解析のまとめ

CaRead1[chid[, count]]

• 引数は、1 or 2でchidハンドルと追加のcount引数を受け取る
• 返り値 {pv-value, alarm-status, alarm-severity, time-stamp}
• エラー
  • 未接続 - CA::Channel
  • タイムアウト - CA::read
  • その他 - CA::read (ヒープ割り当て失敗等を含む)
• 処理フロー
  • 引数検査
  • ca_state確認
  • ca_array_get
  • ca_pend_io
• Filedの扱い
  • STRING/CHAR/ENUM - DBR_TIME_STRINGを要求
  • それ以外 - DBR_TIME_DOUBLEを要求

CaRead2[(chid|Rule[chid, count])..]

• 引数は、1個以上
• 返り値 {({pv-value, alarm-status, alarm-severity, time-stamp}|Null)..}
  • ca_array_getの発行に失敗した場合は、返り値リストの当該要素は Nullに設定される
• エラー
  • 未接続 - CA::unconnected
  • タイムアウト - CA::read
• 処理フロー
  • 引数検査
  • ca_state確認
  • ca_array_get
  • ca_pend_io(リトライあり)

再実装にあたって

• ca_array_getの発行処理、受信データの格納処理は共通化できる
• 引数処理が異なるので、専用のフロントエンド作成するか、共通の中間フォーマットを定義する必要がある
• 引数毎の中間情報は、chid, count, type(callback未使用時), ca_array_getとの共通ポインタを含む必要がある
  • callbackありのケースでは、chidと1:1のslot番号を用いて、itastkへ slot/countを格納し、vstk側にポインタを格納する余地がある(typeは、callback時にevent_handler_argから拾える)
  • 必要な容量はnargオーダーなので、SAD stackframe上に確保出来ると思われる
  • 生のchidを格納する場合は、専用の構造体をSAD stackframe上に作成すべき

_ [雑記]HP DeskJet 5551

長らく使ってきたDeskJet 5551であるが、ついに買い置き在庫のカラーインクカートリッジの最後の1個を運用に投入、純正カラーカートリッジは既に生産終了品なのでこれが切れたら買い替えですねぇ…

天板が平面で小物を上に置けるのが有難い本機の後継機としては、 HP OfficeJet 9110bとHP Smart Tank 7005あたりを検討中

OfficeJetは、CMYK4色とも顔料インクなのが売りだが4色個別のインクカートリッジが結構値がはるのが欠点

Smart Tankは、最近流行りのインクボトルで補給する大容量インクタンク式でインクコストは安いのだが、CMY3色が染料インク

昔ながらのヘッド内蔵インクタンク方式は、ENVYシリーズの流通在庫があるようだが、DeskJet 5551と比べると不満が残る仕様な上に、新機種が出てないので終息か？

あと、DeskJet 5551は変なところで装備が充実していて、ヘッド回りに光学センサーが仕込まれており、給紙タイプの自動判別機能・カートリッジアライメントの自動調整機能が付いているが、最近のモデルは装備してない模様

複合機モデルだとテストプリント結果をスキャナー台で読み取らせて調整する機能があるらしいが、人間が紙を運ぶ必要がある。DeskJet 5551はヘッド部の光学センサーが印字結果を直接スキャンして自動調整してくれるので、トレーに紙があればカートリッジ交換だけで全自動でアライメント調整が完了する完成度が高いシステムです

工業製品的には極めて便利な自動化システムなんだけど、どうして搭載やめてしまったんだろう？ ヘッド内蔵カートリッジをやめたから、インク補充毎にアライメントする必要が無くなったからか？