Linux の swap の優先度の実装2016年02月05日 13時15分27秒

最近、スワップデバイスに興味を持って、少し調べている。

Linux のスワップには優先度の指定が出来るようだ。実装は、優先度の高いものから利用を始め、領域が一杯になったら、次の優先度の領域を使い始める模様。

FreeBSD のスワップには優先度はない。32 個のスワップ領域を保持できる。一つのスワップ領域の最大は、32GB だか 64GB あたりの様だ。

優先度は、一杯になり次第に次に移るのでは無く、割合で並列して全てを使うように出来た方が便利だと思う。

どの UNIX でも ccyymmdd 形式で date を取得2014年07月19日 12時12分58秒

特に Solaris に入っている date が古くて、どのプラットフォームでも動くシェルスクリプトを書くのには気をつかう。Linux などは、/bin/sh といっても現実は bash であり、FreeBSD も ash、AIX などは ksh になっている。Solaris の sh は本当に最古参の物なので、変数を export する時にはしっかり改行しないといけなかったりする程。特に苦手だったのは date の出力の統一。

やっと一番好きな書式をどこでも出せるものを知った。


% date "+%Y%m%d"

で、四桁の西暦、二桁ずつの月日が出せる。

まずは、Solaris から、順次アクセス出来るプラットフォームで。


Solaris % /usr/bin/date "+%Y%m%d"
20140718
Solaris % /usr/xpg4/bin/date "+%Y%m%d"
20140718
AIX % date "+%Y%m%d"
20140718
FreeBSD % date "+%Y%m%d"
20140718
Liunx % date "+%Y%m%d"
20140718

sh -c へ引数を渡す2012年08月28日 15時14分44秒

sh -c を用いてファイルに書かずに、シェルスクリプトを実行出来る。Makefile などで、わざわざ別にファイルを作る程でもない時、csh 系のシェルを使っていてループを使いたい時など、幾つかの場面がある。

そのスクリプトに更に引数を渡すことも出来る。

ただ、厄介なのがその引数の扱われ方。sh -c でコマンドを渡した後に残ったものが、引数として扱われる。そして、面白いことに、一つ目の引数は $0 になり、それに順次続くといった動作になっている。


Solaris % sh -c 'echo $1' one two three
two
AIX % sh -c 'echo $1' one two three
two
FreeBSD % sh -c 'echo $1' one two three
two
linux% sh -c 'echo $1' one two three
two

通常のシェルスクリプト内では、$0 はプログラム自体で、$1 は一つ目の引数になる。sh -c の $1 は二つ目の引数だ。

あちこちのホストで試してみた。長いこと知らなかった。

undefined reference to `vtable for クラス名'2012年05月10日 19時47分47秒

undefined reference to `vtable for クラス名' は gcc が出すリンクエラー。vtable は仮想関数テーブルの略。

仮想関数が宣言されているが、実装が無い時に起きるエラー。対処方法は二つ。

一つ目は関数を実装する。実装するのを忘れて、エラーが出たのなら実装するのは当然のこと。新規のクラスであれば、このエラーが出たからといって、空の関数を書く等してはいけない。往々にして、この空の関数が後で意図とは反する動作になって、自ら首を締めることになる。その場合は、二つ目の対処方法を取ること。しかし、既存のクラスや継承関係に新しい機能を追加する\時に、後方互換のために空の実装を当てなければいけない場合は、仕方が無い。

二つ目は純粋仮想関数にする。この段階のクラスでの実装が出来ないのであれば、純粋仮想関数にして実装は、派生クラスにまかせる。その変わりこのクラス自体のオブジェクトは生成出来なくなる。

動的ライブラリのパスを指定する環境変数2012年02月18日 14時35分50秒

UNIX の動的ライブラリがある場所を指定する環境変数の名前はシステムによって色々と違う。中には同じものを用いるシステムもある。さて、わざわざシステムに依って変数の条件分けをしなくていいと喜ぶべきなのか、システム固有値のみを設定すべきなのか。中途半端な違いが悩みの種だ。

LD_LIBRARY_PATH 派

  • Solaris
  • FreeBSD
  • NetBSD
  • OpenBSD
  • Linux

LIBPATH 派

  • AIX

SHLIB_PATH 派

  • HP-UX

DYLD_LIBRARY_PATH 派

  • MacOS X

awk 演習: realpath を実装2009年03月21日 13時34分23秒

realpath(3) は C 言語の関数だ。FreeBSD はそれを呼ぶコマンド realpath(1) もある。Linux でシェルスクリプトから呼べないので、awk で簡単に仕立て上げた。

/./ がパスに含まれていたら無視、/../ がパスに含まれていたら、/ のルートパスを突き抜けない限り、一番最後の項目を削除する。基本的に先入れ後出しの FILO なので、スタックを用いた実装が適している。


% cat realpath.awk
BEGIN{FS="/"; path[1] = ""}
{ idx = 1;
  for(i = 1; i <= NF; i++)
  {
    if($i == "") ;
    else if($i == ".") ;
    else if($i == "..")
    {
      if(idx > 1)
        delete path[idx--];
    }
    else
      path[idx++] = $i
  }

  if(idx == 1)
    print "/"
  else
  {
    full = "";
    for(i = 1; i < idx; i++)
      full = full sprintf("/%s", path[i]);
    print full;
  }
}

こんな感じの入出力になる。


% cat input.txt
/
/a
/b/c
/d/..
/e/../
/f/../g
/h/../../i
/.
/j/.
/k/./
/l/./m
/n/././o
% cat input.txt | awk -f realpath.awk
/
/a
/b/c
/
/
/g
/i
/
/j
/k
/l/m
/n/o

fstab の第五、第六フィールド2008年03月03日 17時00分26秒

fstab は長い間 sysinstall が最初に作ったものを元に書き足して惰性で作っていた。fstab の第五と第六フィールドは mount には直接関係ないので、あまり注意を払ってこなかった。その為、適当に数字を入れていても特に問題にはなっていなかった。

今回、ふと詳しく読んでみた。まずは、第五フィールド。


The fifth field, (fs_freq), is used for these file systems by the dump(8)
command to determine which file systems need to be dumped.  If the fifth
field is not present, a value of zero is returned and dump will assume
that the file system does not need to be dumped.

このフィールドは dump(8) によって使われる。dump の -w か -W を利用した時にのみ使われる。dump は表示だけで終了するそうだ。どこで見たのかを失念したが、ここには 0 か 1 を入れるとの記述を見かけた。

そして、第六フィールド。


The sixth field, (fs_passno), is used by the fsck(8) program to determine
the order in which file system checks are done at reboot time.  The root
file system should be specified with a fs_passno of 1, and other file
systems should have a fs_passno of 2.  File systems within a drive will
be checked sequentially, but file systems on different drives will be
checked at the same time to utilize parallelism available in the hard-
ware.  If the sixth field is not present or is zero, a value of zero is
returned and fsck(8) will assume that the file system does not need to be
checked.

ここには、ルートファイルシステムのみに 1。fsck を走らせたいファイルシステムに 2。fsck の必要ないフィールドには 0 を入れるとの事だ。/usr の行をコピーして使っていたので、fsck が必要なファイルシステムは偶然にも 2 に設定されていた。

あと、知らなかったのが、何も入れないと 0 と等価な事。uzip/mount_md や nullfs、また readonly などを指定しているファイルシステムも多く、大量の 0 が並んでいる。複数行にまたがる事も多く見づらいと思っていた。消しても問題なさそうだ。

Subversion を使ってみた2008年02月05日 18時47分53秒

あるデータ構造に変更を加える必要が出てきたために、全てのソースコードを点検する必要ができた。どのプロセスが、このデータをどの様に使っているのか、良く判らないために、構造体を変更しただけでは、途中にコピーされるバッファなどが溢れたりする可能性もある。

物凄い量のコードなので、作業をある程度簡単にするべく、リビジョンコントロールシステムを新規に使う事にした。点検する毎にコードを消していき、最終的には全てのファイルが削除される算段だ。

何が使えるかを調べてみると、Linux 上に cvs と svn があるだけだった。古めのシステムで、容易には更新できないシステムなので、比較的新しい物はまだ入っていないようだ。


$ svn --version
svn, version 1.1.4 (r13838)
   compiled Apr 12 2005, 15:59:47

実際にこんな感じだ。

ソースコードの量は半端ではない。900MB に迫る量だ。


$ du -s RELEASE
875140  RELEASE
$ find RELEASE -type f | wc
 126051  126051 6691496

しかし、ここには過去の複数のバージョンが幾つも無造作に突っ込んである為、実際に使われている物は、この十分の一程度だと予想される。

Linux なので、bash が起動している。その為、プロンプトが $ だ。待ち時間を減らすために、tmpfs が使われている、/dev/shm で作業をする。なお、十分なメモリが確保されているのは、点検済みだ。


$ cd /dev/shm/uyota
$ svnadmin create svnrepos
$ cd RELEASE
$ svn import file:///dev/shm/uyota/svnrepos/work/trunk

いつまで待っても終わる気配が無いので、一旦停止して time で時間を計ることにした。比較対象として、cvs でも import をする。

$ csh -c "time cvs -d /dev/shm/uyota/cvsrepos/ import
-m ''Original copy as of 2008/01/10.' work work1 work1_1 > /dev/null"
4.282u 12.214s 0:16.50 99.9%    0+0k 0+0io 0pf+0w

$ csh -c "time svn import file:///dev/shm/uyota/svnrepos/work/trunk
-m 'Original copy as of 2008/01/10.' > /dev/null"
547.692u 17.705s 9:25.57 99.9%  0+0k 0+0io 0pf+0w

cvs が十五秒前後なのに対し、svn は十分近くかかっている。その差は、約四十倍。svn は止めようかなと思い始めた。

折角なので、ディスク容量の比較。


$ du -s *
891100  cvsrepos
875140  RELEASE
789836  svnrepos

チェックアウトしてみる。


$ svn co file:///dev/shm/uyota/svnrepos work
...
A  test/system/scripts/private/info.pl
svn: Malformed XML: not well-formed (invalid token) at line 2208

簡単に調べてみたところ、XML が壊れてしまったようだ。手で、svn の生成した XML ファイルを修正すれば、良いらしい。そこには原因については言及されていなかった。

svn が古いのも原因の一つだろうが、これ以上原因を追求しても、他にも問題に当たりそうな気がする。今回は、svn を使うのを止めた。

Ubuntu がとても不安定2007年10月04日 13時47分39秒

散々と時間を食って、不思議な動作をする HP の dv6425 でだ。FreeBSD のブートが出来ないので、色々と試したのだった。Knoppix やら、他の人から借りた Linux ベースのブート CD。どの Linux CD も難なく起動して、何も問題を見つけられない。

そこで、Ubuntu を実際にインストールしてみた。選んだのは確か、長期サポートの 6.0 系。しかし、その後は芳しくなかった。半々の確率で、起動に失敗する。また、shutdown もほぼ全てといって良いぐらいうまくいかない。Ubuntu は GUI の起動画面で、最初に起動したときこそ綺麗だなと思ったが、それこそが地獄だった。古典的なテキストベースの起動画面であれば、何処で問題あるのかが一目瞭然だが、綺麗なスプラッシュ画面がずっと同じままで、止まっているのか、ゆっくりと動いているのだかの区別すら付かなかった。何度、電源をひっこ抜いたことか。

結局、Ubuntu は正常に起動できないので、諦めるしか無かった。

Linux を使い始めた2007年06月22日 12時09分57秒

処事情により、最近再び Linux を使い始めた。Red Hat なのだが、色々と不具合が目立つ。少し使ってみた感想。

バージョンとかハードウェア構成は良くは覚えていない。Dual Core Xeon だかが 4 機程入っていて、Linux からは 8 CPU として認識されていたと思う。メモリは 16 GB。バージョンはサポートなどの関係で少々古めなのは覚えている。

kswapd や kflushd などが、随分行儀が悪い。時折、システムをロックしてしまい、数秒単位のレスポンスの途切れが結構起きる。こちらは深刻なので後で、時間を取って詳しく調べる必要がある。簡単に調べた結果は、あちらこちらのバージョンで直ったとの記述は幾つか見つけたが、今回使っているカーネルにもパッチが当たっているのかは、一目見ただけでは分からなかった。

また、RPM は最悪のパッケージングシステムなのを再認識した。システムも酷いが、パッケージングのされ方もひどい。コンパイラのバグに当たってしまったので、他にインストールされていたコンパイラを使ってみた。ライブラリやヘッダーファイルが正しくは入っていない。おかげで、ランダムに core を吐くプログラムしか出来ない。結局、コンパイラから自分で作り直して、バージョン管理することになりそうだ。

FreeBSD でも 16GB のメモリのある機械に触ってみたいものだ。