FreeBSD 10.1-RELEASEにMySQL 5.6.22をインストールしたら、おなじみのmy-medium.cnfが無くなっていた。my-default.cnfというものはあるが、中身を見るとどう見ても空っぽ。

公式サイトによれば、5.6.8から従来のcnfファイルの提供は中止され、mysql_install_dbコマンドで生成するようになったらしい。てなわけで実行してみる。

$ sudo mysql_install_db --user=mysql --basedir=/usr/local --datadir=/usr/home/mysql/data
Installing MySQL system tables...2014-12-31 23:47:49 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-12-31 23:47:49 67043 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-12-31 23:47:49 67043 [Note] InnoDB: The InnoDB memory heap is disabled
2014-12-31 23:47:49 67043 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-12-31 23:47:49 67043 [Note] InnoDB: Memory barrier is not used
2014-12-31 23:47:49 67043 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-12-31 23:47:49 67043 [Note] InnoDB: Using CPU crc32 instructions
2014-12-31 23:47:49 67043 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-12-31 23:47:49 67043 [Note] InnoDB: Completed initialization of buffer pool
2014-12-31 23:47:49 67043 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
2014-12-31 23:47:49 67043 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB
2014-12-31 23:47:49 67043 [Note] InnoDB: Database physically writes the file full: wait...
2014-12-31 23:47:49 67043 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB
2014-12-31 23:47:50 67043 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB
2014-12-31 23:47:50 67043 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2014-12-31 23:47:50 67043 [Warning] InnoDB: New log files created, LSN=45781
2014-12-31 23:47:50 67043 [Note] InnoDB: Doublewrite buffer not found: creating new
2014-12-31 23:47:50 67043 [Note] InnoDB: Doublewrite buffer created
2014-12-31 23:47:50 67043 [Note] InnoDB: 128 rollback segment(s) are active.
2014-12-31 23:47:50 67043 [Warning] InnoDB: Creating foreign key constraint system tables.
2014-12-31 23:47:50 67043 [Note] InnoDB: Foreign key constraint system tables created
2014-12-31 23:47:50 67043 [Note] InnoDB: Creating tablespace and datafile system tables.
2014-12-31 23:47:50 67043 [Note] InnoDB: Tablespace and datafile system tables created.
2014-12-31 23:47:50 67043 [Note] InnoDB: Waiting for purge to start
2014-12-31 23:47:50 67043 [Note] InnoDB: 5.6.22 started; log sequence number 0
2014-12-31 23:47:52 67043 [Note] Binlog end
2014-12-31 23:47:52 67043 [Note] InnoDB: FTS optimize thread exiting.
2014-12-31 23:47:52 67043 [Note] InnoDB: Starting shutdown...
2014-12-31 23:47:53 67043 [Note] InnoDB: Shutdown completed; log sequence number 1625977
OK
 
Filling help tables...2014-12-31 23:47:53 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-12-31 23:47:53 67044 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-12-31 23:47:53 67044 [Note] InnoDB: The InnoDB memory heap is disabled
2014-12-31 23:47:53 67044 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-12-31 23:47:53 67044 [Note] InnoDB: Memory barrier is not used
2014-12-31 23:47:53 67044 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-12-31 23:47:53 67044 [Note] InnoDB: Using CPU crc32 instructions
2014-12-31 23:47:53 67044 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-12-31 23:47:53 67044 [Note] InnoDB: Completed initialization of buffer pool
2014-12-31 23:47:53 67044 [Note] InnoDB: Highest supported file format is Barracuda.
2014-12-31 23:47:53 67044 [Note] InnoDB: 128 rollback segment(s) are active.
2014-12-31 23:47:53 67044 [Note] InnoDB: Waiting for purge to start
2014-12-31 23:47:53 67044 [Note] InnoDB: 5.6.22 started; log sequence number 1625977
2014-12-31 23:47:53 67044 [Note] Binlog end
2014-12-31 23:47:53 67044 [Note] InnoDB: FTS optimize thread exiting.
2014-12-31 23:47:53 67044 [Note] InnoDB: Starting shutdown...
2014-12-31 23:47:55 67044 [Note] InnoDB: Shutdown completed; log sequence number 1625987
OK
 
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
 
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
 
  /usr/local/bin/mysqladmin -u root password 'new-password'
  /usr/local/bin/mysqladmin -u root -h MY.HOSTNAME password 'new-password'
 
Alternatively you can run:
 
  /usr/local/bin/mysql_secure_installation
 
which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.
 
See the manual for more instructions.
 
You can start the MySQL daemon with:
 
  cd . ; /usr/local/bin/mysqld_safe &
 
You can test the MySQL daemon with mysql-test-run.pl
 
  cd mysql-test ; perl mysql-test-run.pl
 
Please report any problems at http://bugs.mysql.com/
 
The latest information about MySQL is available on the web at
 
  http://www.mysql.com
 
Support MySQL by buying support/licenses at http://shop.mysql.com
 
New default config file was created as /usr/local/my.cnf and
will be used by default by the server when you start it.
You may edit this file to change server settings

/usr/local/my.cnfが出来たようだ。中身はというと…

/usr/local/my.cnf

# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
 
[mysqld]
 
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
 
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
 
# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# socket = .....
 
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M 
 
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 

これはひどい。どう見ても/usr/local/share/mysql/my-default.cnfをコピーしただけです。本当にありがとうございました。

スクリプトにbasedirとdatadirを渡してるんだから、せめて反映したcnfくらい作ってくれてもいいんじゃないかなぁ…。自分みたいなMySQLの子細は分からないけど、とりあえず使ってみたいユーザーにとっては非常に厳しい。

さて、どうしたものか。

FreeBSDのPortsのnetatalk3が3.1.7に更新された。

今回も

sudo portmaster net/netatalk3

でサクっと更新出来るかと思いきや、gettext-runtimeでエラーが出よる。

/usr/ports/UPDATINGを見てみると、2014-11-30にdevel/gettextがdevel/gettext-runtimeとdevel/gettext-toolsに分離されたのが原因っぽい。

pkg delete -f gettext
portmaster devel/gettext

せよと書いてある。ついでに「これするとsudoがぶっ壊れるので、rootシェルで行う事」と丁寧な注記もあった。

上記操作でgettextの更新は成功したようなので、改めてnetatalkを入れようとしたら、今度は以下のようなエラーが発生。

netatalk3-3.1.7,1 cannot install: no eligible BerkeleyDB version. Requested: 56, incompatible: . Try: make debug-bdb.

BDBのバージョンがおかしいとな。この辺はdb4の駆逐作業後から何も弄ってないハズだし、UPDATINGにも何も書いてないし、「おかしいな」と思いつつインストールされているDBDを確認したらdb48だった＼(^o^)／。VPSの方で行ったdb4駆逐と混同してた模様…。/etc/make.confのWIDH_DBD_VER=56は、どっかからコピペした時に紛れ込んだんだろう。それにしても、今までよく動いてたな……。

DB4→DB5移行の詳細はPorts/BerkeleyDBCleanup - FreeBSD Wikiに書いてあるけど、面倒なのでWIDH_DBD_VER=5にして終了！自宅鯖だからこそ成せる荒業。

そして、ようやくnetatalk 3.1.7が入ったとさ。めでたし、めでたし。

実家にNASを設置しようと思い、7月頃にDN2820FYKHを買ったものの延々放置していた。

ようやく昨日から手を付けだし、使い慣れたNAS4FreeをUSBメモリに書き込んでお手軽NASゲットだぜ!!と思いきや、ブートシーケンスでカーネルパニック起こしやんの。これはBIOSを最新にしたら直ったが、今度はNICを認識してねぇ！

dmesgを見るとre0を生やそうとしてるが「re0: Unknown H/W revision: 0x4c000000」というエラーで蹴られるっぽい。DN2820FYKHのNICはRTL8111Gで、エラーメッセージの通りRTL8111のリビジョン違いらしく、NAS4Free 9.2.0.1というかFreeBSD 9.2-RELEASEではサポートされていない模様。9.2Rのリリース直後、2013年11月頭にパッチが投下されているので、9.3-RELEASEには取り込まれていると思われる。

早いところ、NAS4Freeが9.3Rベースになってくれれば良いんだけどなー。とりあえず、自分でパッチを当ててNAS4Freeをビルドするか、if_re.koを作るかするしかないか…。

(2014-12-01 追記)

if_re.koを自分で作ったら上手く動いたので、以下、手順。

FreeBSD 9.2-RELEASE環境が必要。うちは家鯖が丁度9.2だったが、環境がなければ仮想マシンで仕立てるのが手っ取り早いかと。その場合はカーネルソースも忘れずにインストールの事。

1. Realtekからドライバのソースを落とす。「FreeBSD 7.x and 8.0」となっているが、9.0系でも使える。
2. 展開

   • tar xvzf rtl_bsd_drv_v188.tgz
     cd rtl_bsd_drv_v188

3. ソース修正
   • そのままではコンパイルが通らないので、if_re.cの75行目らへんを修正。

     #include <dev/re/if_rereg.h>
     ↓
     #include "if_rereg.h"

4. make

問題なければカレントディレクトリにif_re.koが出来てるハズ。システム標準のものに比べると、サイズがやたらデカイのが少々気掛かり。

出来上がったif_re.koをFATなUSBメモリにコピーし、DN2820FYKHのNAS4Freeが起動したら挿す。USB周りでエラーっぽいメッセージが出るかもしれないが、まぁ気にしない。以下、挿したUSBはda1として話を進める。

1. NAS4Freeのコンソールメニューからシェルに落ちる（確か6番）。
2. USBをマウント

   • mkdir /tmp/usb
     mount_msdosfs /dev/da1s1 /tmp/usb # da1s1は適宜読み替えの事

3. if_re.koが読み込めるかテストする。読み込めなければ作成に失敗してると思われる。

   • kldload usb/if_re.ko

4. if_re.ko.gzの作成

   • cd /tmp
     cp usb/if_re.ko /tmp
     gzip -9 if_re.ko

5. NAS4Freeの起動USBをマウントし直す。
   • NAS4Freeの起動ディスクは読込み専用でマウントされているので、書き込み出来るようにマウントし直す必要がある。

     umount /cf
     mkdir cf
     mount /dev/da0s1a /tmp/cf

6. if_re.ko.gzをコピー

   • cp if_re.ko.gz cf/boot/kernel

7. loader.conf.localを編集
   • if_re.koを読み込むように設定。

      echo 'if_re_ko = "YES"' >> cf/boot/loader.conf.local

8. 再起動

   • reboot

これでNAS4Free 9.2.0.1でRTL8111Gが使えるようになる。

PS3のHDDを640GBから1TBの物に交換した。

元の640GBは2010年の夏に交換したもので、それから4年、毎月欠かさずPlayStation Plusのフリープレイを落としてた事もあって、残り容量は100GB程度になっていた。

データの移動はPS3内蔵のバックアップユーティリティーで行う。データの移動は「HDD交換前のPS3→外付けHDD」「外付けHDD→交換後のPS3」の2段階で行う必要がある。従って、データがたくさんあると、退避のためだけに大容量HDDを用意する必要があるが、今回は一緒にPS4用にも1TBのHDDを買ったので問題とはならず。どっちかと言えば、時間が超掛かる方が辛い。

ゲームデータ（インストールを要求される奴とか、アップデートとか）を削除した後で移行対象のデータは400GB弱あった。バックアップの所要時間はUSB 2.0で20MB/sとして計算上は5時間半ほどだが、実際に掛かったのは12時間くらい。出勤前に開始し帰宅したら終わってたので正確な時間は分からん。で、復元はというと、なんと丸一日掛かった。途中、プログレスバーが全く進まなくなり、バグってるのかと感じたほど。

足かけ2日掛かったが、とりあえず無事移行出来たっぽい。

引っ越しして金融機関の住所変更するついでに届け印もマトモな物にしようと思い、街のはんこ屋でちゃんとした印章を作った。もう三十路だしね、そろそろ三文判ともオサラバさ。

黒水牛の13.5mmのヤツでお値段4100円。意外と安かった。東京印章協同組合加盟店なら、そう大きく値段は違わないんじゃないかな？書体は篆書体を選択。開運印鑑？なにそれおいしいの？

ネットでも大体同じ位の値段で出てるけど「店舗価格7000円の40%オフ」って価格は本当かよと思う。二重価格なんじゃねーの？

ZFS（のZIL）の断片化では「ギャングブロック」がキーのようなので、理解を深めるべくzio.cのギャングブロックの説明を翻訳してみた。

ギャングブロックは、DMUのような1つの大きなブロックを模倣した、小さなブロックの集合体です。 プールが殆ど満杯だったり深刻な断片化が原因で、zio_dva_allocate()が要求サイズのブロックを見つけられなかった時、それは小さなフラグメントからブロックを構築するためにzio_write_gang_block()を呼びます。

ギャングブロックは、1つのギャングヘッダ(zio_gbh_phys_t)と最大3つ(SPA_GBH_NBLKPTRS)のギャングメンバーから構成されます。 ギャングヘッダは丁度インダイレクトブロックのようなもので、ブロックポインタの配列です。 ギャングヘッダは1セクタしか消費しません。それ故に、断片化にかかわらず確保可能です。 ギャングヘッダのbp(訳注:blkptr_t)はギャングメンバーを指し、それがデータを保持します。

ギャングブロックは、SHA256チェックサムの一意性を保証するための検証値にbpのvdev, offset, txgを用いた自己チェックサムを行います。 重要なのは、そのギャングブロックのbpのblk_cksumはデータのチェックサムであり、ギャングヘッダのものではないという事です。 これは、データブロックシグネチャ（重複排除に必要）の物理的な格納状態に依存しない事を保証します。

ギャングブロックは入れ子になり得ます。つまりギャングメンバーはそれ自体がギャングブロックかもしれません。 それ故に、全てのギャングブロックは、根および全ての内部のノードがギャングヘッダーである木です。また、葉はユーザーデータを含む普通のブロックです。 ギャングツリーの根はギャングリーダーと呼ばれます。

ギャングブロックへのあらゆる操作（読み込み、書き込み、解放、要求）遂行のため、zio_gang_assemble()はまず、ギャングリーダーとその下の全てのギャングヘッダーを再帰的に読むことにより、オリジナルの論理I/Oのio_gang_treeフィールドにギャングツリーを組み立てます（データリーフを除く）。 これは、全てのギャングヘッダとその全てのギャングブロックを構成するためのbpを含む、コア内ツリー（in-core tree）を生成します。

今しがた組み立てられたギャングツリーで、zio_gang_issue()はそのギャングツリーを走査し、各bpのコールバックを呼びます。 ギャングブロックの解放のために、zio_gang_issue()はzio_free_gang()─zio_free()のちょっとしたラッパーを各bpに対して呼びます。 zio_claim_gang()は、同様にzio_claim()のラッパーを提供します。 zio_read_gang()は、ギャングヘッダの読み込みを除くzio_read()のラッパーです。なぜならば、それらはio_gang_treeで既に持っているからです。 zio_rewrite_gang()は、上述したようなギャングヘッダのblk_cksumを更新するために、データのzio_rewriteを、あるいはギャングヘッダについては、ギャングヘッダのzio_reqrite()とデータのzio_checksum_compute()を実行します。

two-phase assemble/issueモデルは部分的失敗の問題─もし、ギャングブロックの一部を読んでいた時に、別の部分へのギャングヘッダが読めなかったらどうなるでしょうか？─を解決します。 解放や確保、書き込みの実際の作業の開始前に、まずギャングツリー全体を組み立てる事は、全ての必須のギャングヘッダーI/Oの成功を保証します。 いったんギャングツリーが組み立てられれば、解放と確保はメモリに対する操作となり、失敗する事はありません。

ギャング書き込み失敗イベントでは、全ての確保済み領域を直ちに解放（すなわち空き領域マップの後ろに追加）するために、zio_dva_unallocate()がギャングツリーを走査します。 これは、あてにならないデバイス（flaky device）が原因のサスペンド・レジュームが繰り返されている間に、ENOSPCを受け取らない事を保証します。

ギャングの再書き込みはsync-to-convergenceの間にだけ発生します。 ギャングツリーを組み立てられなかった場合、そのブロックが変更される事はありません。従って、その解放は安全に保留する事が出来ます。（知っての通りブロックはまだ無傷です。） ギャングツリーを組み立てる事が出来た場合、たとえ再書き込みのうちの幾つかが失敗しても、zio_dva_unallocate()は構成要素の各bpを解放し、次の同期パスで新しいブロックを確保する事が出来ます。

全てのケースにおいて、ギャングツリーは部分的失敗からの完全な復旧に対応します。