gjournalおためしその後

だめくさい。
7.0-RELEASE の GENERICでもだめだわ。というわけで？全部だめ。

+-----------+------+-----+
|  version  | 4BSD | ULE |
+===========+======+=====+
|7.0-RELEASE| BAD  | BAD |
+-----------+------+-----+
|8.0-CURRENT| BAD  | BAD |
+-----------+------+-----+

よくわからんけどスケジューラは無関係。

そもそも async つけてるから当然？？

遂には fsck 中にも panic。しばらく使わないことに決定。。


journal 解除、 soft-updates にした。。

gjournal と SCHED_ULE が悪い？？

ULEスケジューラで gjournal つかってると panic する、気がする。気がするだけ。
今のところこんな感じ

・gjournal の領域は async で mount
・tar展開, 削除繰り返す
・しばらく待つ
パニックした -> BAD
パニックしてない、しそうにない -> good (でも怪しい)

+-----------+------+-----+
|  version  | 4BSD | ULE |
+===========+======+=====+
|7.0-RELEASE| good | BAD |
+-----------+------+-----+
|8.0-CURRENT|  N/A | BAD |
+-----------+------+-----+

んー

gjounal 使用開始後、

csup & カーネル再構築してたらパニックで死亡遊戯
↓
ファイルシステム、ダーティな状態
↓
シングルユーザモード
(マルチユーザモード& background fsck にならず。。)
↓
fsck
↓
起動

したけど、、どうも
・なにかしらの tarball展開
・削除
・tarball 展開
・削除
・・・・を繰り返ししてるだけでパニック。
今まではなかったなぁ。

確実に
panic: ufs_dirbad: /usr/home: bad dir ino 847884 at offset 512: mangled entry

とでるな。んー。CURRENTだからか？
buildworld, buildkernel 時はたまにおきるかな。
7.0-RELEASE でもためしてみよう。

gjournalをつかってみるテスト (再)

前回
は まだソースツリーになかった、けども 7.0-RELEASEから使えるようになった。
man より

HISTORY
     The gjournal utility appeared in FreeBSD 7.0.

CURRENT上で man をみながら使ってみた。小難しいことは一切なし。

/home (は、/usr/home へのシンボリックリンクなのでそのまま /usr/homeで)
/build (/usr/src, /usr/obj 置き場)
を それぞれ 別ディスク用意して(Parallels のVMなのでラク) gjournal に。
ジャーナル分で結構容量食うみたいだ。。
元のディスクは
ad2: 12G
ad3: 4G
で作成。

% df -h -t ufs
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a         496M    362M     94M    79%    /
/dev/ad0s1e         496M    3.9M    452M     1%    /tmp
/dev/ad0s1f          28G    2.4G     23G     9%    /usr
/dev/ad0s1d         1.2G    158M    970M    14%    /var
/dev/ad2.journal     10G    5.0G    4.5G    52%    /usr/home
/dev/ad3.journal    2.8G    1.5G    1.1G    59%    /build

% mount -t ufs 
/dev/ad0s1a on / (ufs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)
/dev/ad2.journal on /usr/home (ufs, asynchronous, local, gjournal)
/dev/ad3.journal on /build (ufs, asynchronous, local, gjournal)

サーバ落としたりリブートするときは gjournal sync しないといけない風なので、(ソース: man, 2ch)、/etc/rc.shutdown にこんなん追加してみた、けどこれでいいのかな。。

gjournal_sync_count=1
while [ $gjournal_sync_count -le 5 ]; do
  echo -n "Gjournal sync${gjournal_sync_count}..."
  gjournal sync -v
  gjournal_sync_count=$(expr ${gjournal_sync_count} + 1)
  sleep 1
done

この処理のあと syncing disks.... が走るわけなんだが、man とは逆順になってしまってるなぁ。。うーん。

The most important one is that sync(2) and
     fsync(2) system calls do not work as expected anymore.  To ensure that
     data is stored on the data provider, the gjournal sync command should be
     used after calling sync(2). 

/etc/fstabはこんなん (ufsのところ抜粋)、/boot/loader.conf に geom_journal_load="YES" を追加。まぁ適当に。

/dev/ad0s1a  /  ufs rw  1 1
/dev/ad0s1e  /tmp  ufs rw  2 2
/dev/ad0s1f  /usr  ufs rw  2 2
/dev/ad0s1d  /var  ufs rw  2 2
/dev/ad2.journal /usr/home ufs rw,async 2 2
/dev/ad3.journal /build  ufs rw,async 2 2

% grep geom /boot/loader.conf
geom_journal_load="YES"

とごそごそやってみたものの、ベンチとる気は起きない。。
async だけどジャーナルのぶん、遅い気がする。