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上に作成すべき