井田で潜ってきた

先週10/04、井田へ行ってきた。
当日、波は穏やかだったが、数日前の爆弾低気圧の通過の影響で、波止場にも岩や砂が上がってきていた。
海の様子もだいぶ違う。水中生物も流されたり移動したりで、どこに何がいるかわからない。

とりあえず何枚か写真を取ったが、どれも見栄えがしない。

今年は黒潮の当たりがあったので、死滅回遊魚も多い。

武蔵野線の地下区間でａｕがつながる？

武蔵野線の西のほう、府中本町駅〜新秋津駅は半分地下鉄のような感じだ。
ガラ携の頃から、この地下区間は圏外だった。
ずーっと地下ならいいが、地上と地下が混ざっているため、着信後に地下に入って切れたりとかするので、電話をしてきた人には感じの悪いことになる。

「今武蔵野線だから…」と言っても、武蔵野線の東側しかしらない人は、頻繁に地下に入るというのを理解出来なかったりして、面倒なことになる。実際に船橋付近に住む姉から緊急の電話があった時、携帯が切れまくって「なんで切るんだよ！」みたいに切れられたことがあった。
「武蔵野線の西側は半分地下鉄みたいなもんなんだよ」と説明しても、実際に理解されなかった。

今日、帰ってくるときに携帯を操作していたら、西国分寺〜新小平、新小平〜新秋津の２ヶ所で、いつまでも電波が切れず、ネットをアクセスできた。
ちなみに、キャリアは ａｕ(KDDI)。 厳密には時々アンテナの本数が0になっている時もあったが、数秒で復活した。ニュース記事をみたり、チャットしたりするには十分な感じだった。
少なくとも数日前は、地下に入ると切れていたと記憶している。

いつの間にそんなことになっていたんだろうと思い、ネットでニュースを検索するが、それらしい記事は見つからない。
まだ実験段階なのか？
武蔵野線の地下区間で携帯がつながるとしたら、便利になる。
是非とも、しっかりとつながるようになってほしい。
ガンバレａｕ。

圧縮イメージをマウントする

2017/12/15 追記: Ubuntu16.04では、Lubuntu 16.04 でｘｚ圧縮イメージをマウントする を参照せよ。

---

CFカードやSDカードにデータを記録する装置を作って、もう１５年以上。
Flashメモリは寿命のあるデバイスである。CFカードもSDカードも中身はFlashメモリなので、装置運用時にカードが壊れてしまうことがある。
お客さんからそのようなカードが持ち込まれ、できる限りデータを回収して欲しいと依頼されることもある。
その装置で記録するデータの構造は比較的単純なので、イメージさえ入手できれば比較的簡単に取り出せる。

Flashメモリの寿命が原因ではなく不具合が原因かもしれず、それは調べてみなければわからない。
また、開発時の動作確認時や長期連続試験をしているときに、カードの記録データが壊れてしまうことがある。
特に長期に渡る試験のとき、事故発生前はカードがどういう状態だったのかを知りたいことがある。時間を遡ることはできないので、時々イメージをbackupしておく。
自分で作った装置なので責任もあるし、壊れ方から原因を理解したり、回復方法の習得にもなる。

と、いうことで調査のためカードのイメージをとっておく。
(お客さんのデータは、お客さんのものなので、早期に破棄する)
イメージをとっておけば、linuxならloopデバイスを使ってマウントでき、後から過去の状態を参照できる。

CFカードやSDカードとは言っても、最近は大容量なので、ストレージ領域を消費する。
もったいないので、圧縮しておきたいが、圧縮イメージは普通にはマウントできない。
read-onlyでいいからマウントできればいいのだが、gzipやbzip2はランダムアクセスのためのデータ構造を持っていないので、ランダムアクセスするためには全体を展開する必要がある。
近年のSDカードは巨大で数十GiBもあり、展開する時間も記憶域容量も馬鹿にならない。

gzipを拡張したdictzipというものがあり、ランダムアクセスのためのテーブルを持っている。しかし、そのテーブルをファイルの先頭に配置するため、パイプで処理できないという欠点がある。bzip2は、開発時にランダムアクセスの仕組みを入れるかどうかという議論があったが、やめたそうだ。ブロックをスキップしながらアクセスする方法もあるのだが、１つずつブロックをスキップしなければならないため、効果が低い。

---

数年前からxzという圧縮ツールがある。
圧縮ファイル内をblockと呼ばれる単位に分けることができ、そのblockのインデックス情報も持っている。
インデックス情報を参照することでblockの粒度でランダムアクセスができる。
dictzipに似るが、インデックス情報は、ファイルの末尾付近にある。
そのため、データの圧縮が終わった後で、インデックス情報を構築し末尾に格納することができ、パイプで処理できる。

ファイルの末尾にインデックス情報があると、インデックス情報を読むためには、全体を読まないといけないような気がするかもしれないが、そんなことはない。seekして、最後の方だけ読めばいい。
ランダムアクセスを行おうとしているのなら、ファイルのseekができるはずで、seekができるならファイルの末尾にインデックスがあっても全く問題ない。

xzは比較的新しい圧縮方法だが、LinuxのLiveCDで使われるsquashfsでもサポートされるなど、様々なシーンで利用されており、実績も徐々に上がってきている。
Ubuntu12.04のxz-utils(xzのバイナリパッケージ)のchangelogをみても、

$ apt-get changelog xz-utils | head -n 30
取得:1 xz-utils (http://changelogs.ubuntu.com/changelogs/pool/main/x/xz-utils/xz-utils_5.1.1alpha+20110809-3/changelog) の変更履歴 [25.5 kB]
xz-utils (5.1.1alpha+20110809-3) unstable; urgency=low

  * liblzma: Match upstream ABI.
    - Remove the lzma_chunk_size() function.
    - A few ABI tweaks to reserved space in structures.
    - Enable ELF symbol versioning.
    - Bump soname to 5.
    - Continue to leave out threading support, since the relevant
      interfaces in liblzma are not yet stable.
  * xz-utils/README.Debian: Remove note on ABI differences.
  * Remove liblzma/README.Debian.
  * liblzma: Introduce a lzma_code@Base compatibility symbol to ensure
    programs linked against unversioned symbols from liblzma2 can
    share a process image with liblzma5 without breaking.
  * debian/symbols: XZ_5.0 symbols come from liblzma5.  Build-Depends:
    dpkg-dev (>= 1.15.6); thanks to Jakub Wilk for a reminder.
  * debian/symbols: The lzma_code@Base symbol is not guaranteed to
    continue to exist in the future, so tell dpkg-shlibdeps to produce
    an error if some package manages to use it.

 -- Jonathan Nieder   Thu, 20 Oct 2011 21:31:31 -0500

xz-utils (5.1.1alpha+20110809-2) unstable; urgency=low

  * debian/rules build-arch: Do not trigger an infinite "make"
    recursion loop when DEB_BUILD_OPTIONS=nocheck.  Closes: #638071.
    Thanks to Thorsten Glaser.

 -- Jonathan Nieder   Tue, 16 Aug 2011 18:11:47 -0500

という感じで、最後の変更は2011年10月20日だ。利用されているのに変更や更新はない。バージョンに"alpha"の文字が見られるものの、安定していると言える。
最新のwilyでも"5.1.1alpha+20120614-2ubuntu2"で、更新がほぼ無い(alphaのままだ)。

---

実は、このxzで圧縮したイメージをマウントする方法がある。
圧縮イメージを、NBD(Network Block Device)経由で、ブロックデバイスにしてマウントするのだ。
この場合、書き込みはできないのだが、CFカードやSDカードのイメージを壊したくはないので、むしろ都合がいい。

必要なものを入手する

NBDを動かすには、nbd-server, nbd-client が必要だ。
xz圧縮イメージをNBDで扱うには、nbdkit も必要だ。
しかしながら、Ubuntu12.04(NautilusでCompactが使えるので未だに使い続けている)の場合、nbdkitのパッケージが無い。
そのため .debは諦めて .tar.gz を入手して、自分でビルドしてインストールする。
ただし、これをビルドするには、libmodule-build-perl と libperl-dev パッケージが必要になる。

まずは、必要な.debパッケージをapt-getで入手する。

$ sudo apt-get install nbd-server nbd-client libmodule-build-perl libperl-dev

nbdkitの .tar.gz を入手する。 このページの下の方のTarBallsへのリンクから、nbdkit-1.1.10.tar.gzを得る。 wgetで入手するなら、

$ wget http://libguestfs.org/download/nbdkit/nbdkit-1.1.10.tar.gz

nbdkitのビルドとインストール

適当なディレクトリを作って、ビルドする。

$ mkdir xxxx
$ cd xxxx
$ tar -zxvf ../nbdkit-1.1.10.tar.gz
      (サブディレクトリnbdkit-1.1.10ができる)
$ cd nbdkit-1.1.10
$ ./configure
    (いろいろ表示される)
$ make
    (いろいろ表示される)
$ make check
  : (省略)
============================================================================
Testsuite summary for nbdkit 1.1.10
============================================================================
# TOTAL: 8
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
  : (省略)
    (全部パスしたようだ)
$ sudo make install
    (いろいろ表示される)

xz圧縮イメージの用意

xz圧縮イメージなら、何でもいいというわけではない。
block単位でしかseekできないという事を忘れてはいけない。xzはデフォルトではデータ全体を１つのブロックとして圧縮してしまう。この場合、全体を展開しないといけないので、本末転倒だ。
小さなブロックに分けるのが良い。
ネット上を検索すると、プリセットレベル -9 ブロックサイズ16MiBで行う例がよく見られるが、これには疑問を感じる。
まず、xz の man page上で以下のような書き込みがある。

          : (省略)
   -0 ... -9
      Select a compression preset level.  The default is -6.  If  mul‐
      tiple  preset  levels  are specified, the last one takes effect.
      If a custom filter chain was already specified, setting  a  com‐
      pression preset level clears the custom filter chain.

      The  differences  between  the presets are more significant than
      with gzip(1) and bzip2(1).  The  selected  compression  settings
      determine  the  memory  requirements  of  the decompressor, thus
      using a too high preset level might make it  painful  to  decom‐
      press  the file on an old system with little RAM.  Specifically,
      it's not a good idea to blindly use -9 for  everything  like  it
      often is with gzip(1) and bzip2(1).
          : (省略)

自分なりに訳してみると、

          : (省略)
   -0 ... -9
      圧縮プリセットレベルを選択。デフォルトは-6だ。複数のプリセット
      レベルが指定されたら、最後の１つが効果をもつ。カスタムフィルタ
      チェーンがすでに指定されていたら、圧縮プリセットレベルの設定は
      カスタムフィルタチェーンをクリアする。

      プリセット間の違いは、gzip(1)やbzip2(1)でのよりも意味深い。
      選択された圧縮設定はデコンプレッサのメモリ要求を決定し、そのため
      高すぎるプリセットレベルは、少ないRAMの古いシステムで、その
      ファイルを展開するのに痛みをともなわせることになるだろう。特に
      gzip(1)やbzip2(1)でしばしば見られるように、なんにでも盲目的に
      -9を使うのは良い考えではない。
          : (省略)

また、ブロックサイズは辞書サイズの３倍ぐらいが良いとどこかに書いてあった。
(すっかり忘れっぽくなったものだ。)
特に辞書サイズよりもブロックサイズが小さいと、辞書のために確保したメモリが無駄になってしまうためだ。
プリセットレベル -9 の辞書サイズは 64MiBであり、16MiBとは完全に逆転している。
という訳で、プリセットレベルが -9 で、ブロックサイズが16MiBがおかしいのは解ってもらえたと思う。

じゃ、どのへんが良いだろうか？
私はこの古いVAIOも使っている。これでもそこそこ使えないと困る。
このマシンはメモリが極めて少なく非力でもあるので、プリセットレベル -0 ブロックサイズ 1,048,576(1MiB)とする。

具体的な圧縮方法が決まったので、以下のようにしてxz圧縮する:

$ zcat sd64GB.img.gz | xz -0 --block-size=1048576 > sd64GB.img.xz

上記は元データがgzipで圧縮されていた場合の例だ。

NBDの提供

圧縮ファイルの用意ができたら、圧縮ファイルをNBD(Network Block Device)として提供しよう。
提供するには、nbdkitを使う。

$ sudo nbdkit --user xxx --group xxx -i 127.0.0.1 xz file=sd64GB.img.xz

xxxはユーザ名だ。 子プロセスが起動し、バックグラウンドでndbサーバが動作する。
デフォルトではポート番号は10809になる。-pで任意のポート番号を指定することもできる。
後で止めるには、psで、nbdkitを探してkillせよ。

デバイスノードを作る

サーバが動き出したので、ndb-clientでデバイスノードを作る。

$ sudo nbd-client 127.0.0.1 10809 /dev/nbd0 -nofork

これで/dev/nbd0でブロックデバイスが見えるようになる。
パーティションが/dev/nbd0p1で参照できる。

マウントする

デバイスノードができたらマウントだ。

$ mkdir sd64GB
$ sudo mount /dev/nbd0p1 sd64GB -o ro,uid=xxx,-gid=xxx 

xxxはユーザ名だ。適切なユーザ名を指定せよ。 FATならこれでいいのだが、ジャーナリング機能をもつext3やext4では、イメージが汚れている場合マウントできない。
read-onlyなので、ジャーナルをリプレイできないため、汚れをきれいにできないのだ。
この場合、noloadオプションを使って、マウント時のジャーナルの再生を抑制する。

$ sudo mount /dev/nbd0p1 sd64GB -o ro,noload 

---

これで、圧縮イメージ内を参照できるようになる。
ext3やext4のマウント方法も書いたが、これらの内容を圧縮したいなら、ブロックデバイスイメージを圧縮するよりも、squashfs等を使ったほうがいいだろう。

私は職業柄、問題調査のためFATフォーマットされたCFカードやSDカードのイメージを、未割り当て領域も含めて保存し、後から参照したいので、このような手段を使っている。

---

2015/09/19 一部訂正。

今日のケーニッヒ

中心付近の葉っぱは、13枚目の葉っぱ。
先週出てきた。次の芽が続かない。

12枚目の葉っぱが、虎模様のようになってる。
急に大きくなったからか？今度は何だろう。

２週連続ダイビング

先週に続いて、今週もお泊りダイビングに行ってきた。

当初の予定では、IOP(伊豆海洋公園)と井田の予定だったが、天気がイマイチだったので、大瀬崎と井田になった。
大瀬崎は先週も潜っていたが、先週の２日目は二日酔いで２本目をキャンセルしていたので、消化不良気味だったので、ちょうど良かった。

潜ってみると、先週よりも水温と透明度が上がり、いい感じになっていた。
さらに、先週は「大瀬崎・先端」が遊泳禁止だったが、今週は潜れるようになっていた。

ツノダシ

ミジンベニハゼ

先端では、キンギョハナダイやスズメダイが元気だったが、ちょこまか動くのでうまく撮影できなかった。
それにしても、動画の手ブレがひどい。
こういうのは、カメラを固定して撮らないとダメかも。

結局、大瀬崎では４本潜った。
その後、井田の天野荘へ移動して、一泊。

次の日、起きると外は雨。しかし、海を見ると、波も少なく良さそう。
潜ってみると、ぶち抜け。下の方は、透明度20mぐらい。
鉄パイプの枠組みから、下の二股の木がはっきり見える。すごい透明度なのに水温が高い。
おそらく、黒潮が来たのだろう。何度も井田で潜っているが、こんなにすごいのは初めてだ。

透明度が高いので、中層の群れがすごくいい。
しかし、もともと井田の群れはすごいので、動画で撮影しようとしてもうまく撮影出来なかった。

失敗覚悟で、ピンナップを色々撮った。

キンギョハナダイ

ソラスズメダイ

ナガサキスズメダイ

ネンブツダイ

ハタタテ

透明で暖かく、楽しいダイビングだった。

夏のバカ男

先週、8/22〜23 ダイビングショップ Feel The Seaの、Diving & BBQ に行ってきた。
場所は大瀬崎。昼はダイビング、夜はBBQと花火をする。

台風15号＋16号が接近、しかも、どちらもスーパー台風級だったので心配だったが、さすが大瀬崎。
湾内は全く問題ない。水温も高く27℃。下の方は水温も下がるが、透明度も高い。
数年ぶりにまっちんも参加。

初日は、３本潜った。

入ったらすぐ、大きなひらめ。50cm Over。

ヤガラが逃げなかったので撮影。

あまり写真は取らなかった。水温が高かったので、遊ぶのを優先した。

夜になって、BBQのとき、飲み過ぎてしまい、次の日は二日酔い。
一本目、潜ってみると、透明度がかなり回復していた。
しかししばらく潜っていると寒い。飲み過ぎた後は、たいていこうなる。
短時間なら耐えられるのだが、長時間は無理。体内で熱が作れない感じ。
途中から、みんなよりも5mくらい上に上がる。
上がってくるときにネンブツダイの稚魚の群れがいた。

寒すぎて、写真もほとんど撮らない。

安全停止で待っている時も寒い。
体をできる限り縦にしない姿勢をとるが、そうするとお腹の中のものが逆流してくる感じがする。
体を縦にすれば、逆流は楽になるが、背中からどんどん熱が逃げて寒い。

ゴロタを上がって、水平の砂利地帯に入ったあたりで、ゲロを吐いてしまった。
魚たちは大喜び。
田中さんに手話で「一人で先に上がります。」と伝えて上がった。

その後、2本目はキャンセルした。

考えてみたら、昨日は日焼けして脱水気味なのに、買っておいたお茶を紛失して、水分補給が出来なかった。
ダイビング後も、BBQまでドタバタして、水分補給をせず、BBQでビールや焼酎を飲んでしまった。
その後疲れていたので、やはり水分補給をせずに寝てしまった。
朝食時にお茶をたくさん飲めばよかったが、急須が手元になかったので、遠慮して飲まなかった。二日酔いが始まっていたので、急須を取りに行くのが面倒だったというのもあった。
結局、ほとんど水分補給をしていなかったのだ。

１本目の後で、500mlの水を買って飲んで横になっていたら、すぐに回復。
しかし、潜らなかった。

初日に３本潜ったので、差し引き０だが、もったいないことをしたものだ。
いつも飲酒で失敗する。もう少し締めてかからねば。

今日のケーニッヒ

ケーニッヒは少しずつ元気になり、１２枚目の「３枚葉っぱ」の付け根部分は、赤くなく、きれいな薄緑になった。
葉っぱの大きさも、とても大きい。
さらに中心部からも新しい芽が出てきている。これも葉っぱかな？
ランナーはまだかな。。。

変色していた下の方の葉っぱは、いよいよダメになってきた。
下の方の葉っぱは小さく非効率だし、大きな葉っぱが揃ってきているので、無くなるのもアリなのかも。

ケーニッヒ途中まとめ

ケーニッヒ(いちごの苗)の記事を、統一性もなくだらだら書いていたので、良くわからなくなっている。
まだ続けるのだが、ここでまとめておく。

通し番号	タイトル	備考
1	いちごの種を撒いてみる。	最初の記事。ケーニッヒの前に発芽した芽。これは死んでしまう。
2	いちごの苗	最初のケーニッヒの記事。双葉が３枚、根が２本の芽が出た。キングギドラー のようなので、ケーニッヒと名付けた。
3	今日のケーニッヒ
4	ケーニッヒその他	ケーニッヒに加えて、近所の草木。
5	今週のケーニッヒその他	ケーニッヒに加えて、さくらんぼと桑の実の採集など
6	今週のケーニッヒ
7	大丈夫か！？ケーニッヒ	元気がなくなる。
8	今週のケーニッヒ	明らかに元気がなくなる。
9	今週のケーニッヒ	生還を待ちつつ、静観
10	復活なるかケーニッヒ・ギドラー	水洗い作戦
11	がんばれケーニッヒ	直射日光は禁物

そして、今日のケーニッヒ。

色が悪くなった葉っぱや、赤くなってしまった葉っぱが痛々しい。
肥料のやりすぎ、光の当てすぎ。
経験が無いとは言え、自分の猪突猛進ぶりを多少反省しつつ、この失敗から学んだことを今後に生かしていこう。
いつまでもくよくよせずに、前向きに。
子株では失敗しないぞ。

がんばれケーニッヒ

洗い流し作戦以降、もともと弱っていた第１〜第３の「３枚葉っぱ」は、枯葉色になってしまった。
特に、第１の３枚葉っぱは、完全に枯葉になって、カリカリになってしまった。
しかし、他はぎりぎり助かった。なんとか危機的状況は脱したようだ。

しかし、新たな問題が発生。
比較的新しい葉っぱの表面に、濃い赤色が刺すようになった。おそらくストレス物質のアントシアニンだろう。
今までにはない。今度のストレスはなんだ？
考えられる原因としては、暑さだ。
洗い流し作戦で水浸しにした後で、寒かろうと思い、いつもよりも長く、太陽を追いかけるようにして、直射日光の下に出していたのだ。
その時に、葉の一部が赤黒くなった。

暑い日も続いていた。気温も高い。
そんな時に直射日光を長時間浴びたので、ストレスになったのだろう。

いちごは、ヒマワリのようにスッと高く伸びる植物ではない。
どちらかといえば、地を匍うような植物だ。真冬でも枯れることがなく、冬の終わり頃、まだ他の植物が目を出す前に葉を広げ、先に成長する道を選んだ。
ノイチゴやヘビイチゴ等をみていると、６月以降は他の植物に高さで抜かれ、埋もれてしまう。夏の暑い時期には光が当たっていないのだ。

これらのことから、直射日光、特に暑い時期のやつは、避けるべきかもしれない。
ベランダ(というか、物干し台)の日陰にいちごを置くようにした。
すると、またすくすくと育ち始めた。

いろいろ勉強になる。

中央付近、１０枚目の「3枚葉っぱ」が出てきた。
もうそろそろ、ランナー(匍匐茎)と呼ばれるものが出てくると期待しているのだが、その兆しは今のところ無い。

またまた井田へ行ってきた

先週の7/26(日)にまた井田へ行ってきた。

黒潮が接近しているので、海に行きたくてしょうがなかったのだが、台風が次々と発生＆接近し、なかなかダイビングに行けなかった。
台風１２号は、一度は消滅したくせに復活してしまった。当初は本州直撃もありうる予報だったが、結局東シナ海へ流れて行った。
とはいえ、前日までフィリピン海に台風があったのだ。うねりは残っている。

通常、正面のゴロタからエントリする。たしかに、一本目はここからエントリした。
でも今日はこのうねりだ。ゴロタで足元はおぼつかず、大きなうねりは、岩をも転がし危険である。よく見ると、右側のスロープは比較的うねりが少ない。
このスロープは本来、漁業のための施設で、船を揚げるためのものだ。通常なら、ダイバーは使えない。
しかし、この時期は海水浴客も来ており、海水浴客は右側のスロープから海に入っていた。
ということで、２本目は特別に右側のスロープからエントリーとなった。

初めて右側からエントリした。入りやすく、透明度が高く、ゆっくり見たかったが、釣り人の邪魔にならないように「止まらずに通過せよ」と指示されていたので、残念ながら見れなかった。海は誰のものでもない。みんなのものである。しょうがない。

キビナゴの群れ

アカエイ２匹

今年は台風は多いが、黒潮が接近しており、水温と透明度が高い。
まさしくダイビングにはうってつけだ。今年は当たり年かもしれない。