厳密な順序での ZFS スナップショットの列挙

本エントリは Solaris Advent Calendar 2016 の 20 日目です。

動機

既存の ZFS なファイルシステムから、別プールに複製を作成する場合、zfs send + zfs receive を使うのが一般的です。

しかし、そもそも zfs send で指定するスナップショットは、どうやって特定すればよいでしょうか？

例えば、「最新」のスナップショットを使って zfs send を実行する場合、手動での実行なら「目視判定」でも構わないでしょうが、スクリプト等で自動化するなら、何らかの新旧判定基準が必要です 。

新旧判定に属性情報を使用するにしても、zfs get all 出力を見る限りでは、使えそうなものが見当たりません。「作成日」を保持する creation 属性は、単位が「秒」なので、厳密な順序関係を判定する用途には不適切です(まぁ、実運用上は問題無いケースの方が多いと思いますが……)。

beadm コマンドの舞台裏

本エントリは、Solaris Advent Calendar 2016 の 16 日目です。

「ENOSPC だと beadm destroy できない」問題

先日、久々に仮想環境ゲストの OpenSolaris 上で pkg update を実行したところ、新規ブート環境 (Boot Environment: BE) が作成された上で、大量の更新が実施されたことで、rpool の容量があふれてしまい:

• "No space left on device" (ENOSPC) で pkg update が失敗
• beadm destroy 新規BE も ENOSPC で失敗
• 再起動すると、メンテナンスモードに突入
• メンテナンスモードでも beadm destroy 新規BE は不可

上記のような、にっちもさっちもいかない状況に陥ってしまいました。

新規 BE はアクティブ化もされていない状況だったので、サクっと破棄できそうな気がするのですが、どうやら beadm destroy 新規BE の際に実施されるマウント処理が、ENOSPC で失敗してしまう模様です。

このような状況で、状態を正常化するには、beadm コマンドの内部的な実現方式を把握しておく必要があります。

ノートPCを新調 (Let's note CF-SZ6 ドライブレスモデル)

2014 年に以下のような梃入れで延命を図った CF-J10 ですが:

• メモリ増設 (16 GB 化)
• キーボード補修 (Caps Lock キー交換)
• バッテリー交換

その後もいくつか補修を行うことに。

• Caps Lock キー以外もダメになったので、キーボード全交換
• 冷却ファンが時折異音を発する (おそらく偏芯?) ため、冷却ユニットを交換

これで当分は安心して使えるだろう、と思っていたのですが:

• C ドライブの SSD の空き容量が、総メモリ量の 16 GB を切ってしまった
• 内臓 Wi-Fi が完全にダメになったが、USB の Wi-Fi モジュールだとバッテリー駆動時間が激減

前者だけなら、256 GB 程度の SSD に換装するという手もありますが、ここまで来たなら製品的な寿命と考えて、ノート PC を新調するのが良さそうです。

2014 年時点では碌な買い替え候補がなかったのですが、幸いな事に今回は多くの候補に恵まれました。

『俺のコードのどこが悪い？』へのご意見・ご要望・誤記情報

拙著『俺のコードのどこが悪い？』に対するご意見・ご要望・誤記情報等ありましたら、本エントリへのコメントとして書き込んでいただければ、可能な範囲(私個人のサポートページへの掲載等)で対応させて頂きます。

twitter 経由なら @flyingfoozy 宛てにお願いします(1/day ぐらいしか確認してませんが ....)。

俺のコードのどこが悪い?

なお、副題の「コードレビューを攻略する４０のルール」とか「失敗に学ぶ成功の法則とは？」といった大仰な物言いは、販売戦略上から編集さんの意見で付いたものなので、「(この内容で)それってどうよ？」みたいな意見に関しては、私に寄せられても困ります(笑)。私自身も未だにちょっと気恥ずかしいです ＞ 煽り文

書籍中にも書きましたが、本書で取り上げた40項目は、「これさえやれば」的な項目ではなく、「少なくともこれぐらいは」的な項目です。

各自がより有用な確認項目作りをする際の、最初の叩き台として本書が微力なりとも読者のお役に立てば幸いです。

渡米時のモバイル通信環境に関する備忘録

先日、Mercurial 3.8 Sprint でサンフランシスコに行った際に、現地でのモバイル通信環境を確保するために、事前調査した内容と、実際に現地で確保した通信環境を使用してみての感想を、備忘録代わりに公開しておきます。

前提条件

異郷での一人旅では、「確実にネットワークに繋がる」＋「Google Map が使える」が何よりも頼もしいことを、前回のロンドンでの Mercurial 3.6 Sprint で痛感させられたので、今回も現地で SIM を調達することにしました。

前回は手元にある機材が Nexus7 だけだったので、Nexus7 用のデータ通信 SIM に加えて、通話用に別途現地で格安 Nokia 端末を入手しましたが、今回は新たに入手した ASUS ZenFone2 (ZE551ML) でデータ通信(テザリング含む)／通話／SMS を全て賄うことにします。まぁ、通話は全然使いませんけどね（笑）

ちなみに、今回の旅程は:

• 木曜日: 現地到着(夕方)
• 金曜日 〜 日曜日: 終日 Sprint
• 月曜日: 終日観光 〜 深夜発の便で帰国

という感じで、あまり観光の時間が取れないことから、データ通信量は 1GB もあれば十分と思われます。

2015 年を振り返る＆2016 年の抱負 (後付け)

帰省期間に、実家の家電/IT周りを中心とした保守業務に忙殺されて書き損なってしまったのが災いして、結局ズルズル書かず仕舞いだった「2015 年を振り返る＆2017 年の抱負」ですが、とりあえず記録がてら、枠を埋めるだけでも埋めておこうと思った次第です (@2017-01-01)

Mercurial 関連活動

● Mercurial 本体への貢献

2015 年の成果はコミット数ベースで 181 件 (うち翻訳作業が 7 件) なので、「コミット数ベースでは、月10件平均で総数120件」は達成できましたが、去年が 280 件だったので、気分的にはちょっと残念な感じです。

Mercurial に関するコミュニティ由来の成果(2015年版)

本エントリは、2015年の一年間に、ML/twitter/勉強会といったコミュニティから上がった情報／要望の中で:

• Mercurial 本体に取り込まれた修正の契機になったもの
• Mercurial 本体に取り込まれてはいないものの、何らかの成果に結びついたもの
• 『今後の作業のネタ』(＝ バックログ)として認識されているもの

上記に該当するものを、情報提供への感謝の意味も込めて、列挙したものです。
『気になった点に関して、情報提供をする』だけでも、十分開発に貢献できる事の証拠とも言えます。
今後も、Mercurial に関して疑問／質問／要望等があれば、お気軽に情報をお寄せください ＞ 利用者の皆様

情報をお寄せ頂く手段に関しては、"Mercurial で困った時に" をお読みください。

なお、以前のものは、以下から参照できます。

• 2012年版
• 2013年版
• 2014年版

本体に取り込まれた修正(changed by 藤原)

以下に列挙するものは、コミュニティからの情報を元に私が提案した修正のうち、Mercurial 本体に取り込まれたものです。
なお、私の手による修正履歴一覧から、記憶を頼りに目視で抽出したものなので、『俺の情報を元にパッチ作成しておいて手柄を独り占めかよ！？』的なものに心当たりがある方は、お気軽に情報をお寄せください(笑)。