続：FreeBSDのdump -Lってzfsに対応してますか？

昨晩書いた話の続きなんですが、一晩よく寝て改めて確認してみたら、いくつか勘違いしていることに気づきました。話を整理しましょう。

まず、dumpは伝統的に ファイルシステム単位でバックアップするものであり、tarやrsyncなどのようなファイル単位でのバックアップツールではないこと。
よって、ファイルシステムが異なる場合は、それに対応するダンプ用のコマンドを用いるのが適切であること。例えばSolarisであればufsdump/ufsrestoreという名前になっている。

zfs send は snapshotをダンプするコマンドであること。よってdump -Lとは扱いが異なる(バックアップ前に手動でsnapshotを作る作業が必要？)。dumpと同様に標準出力やファイルへの書き込みが可能なので、バックアップ先のファイルシステムは問わない。ただしFreeBSD 8.0RC1のマニュアルには

The format of the stream is evolving. No backwards compatibility is
guaranteed. You may not be able to receive your streams on future
versions of ZFS.

などと書いてあるのでOSのメジャーアップデートの際は気をつけましょう。

実際のところ、FreeBSDのdumpはzfsに対応していません。FreeBSD/amd64 8.0-RC1で実行しようとすると。

# df /home
Filesystem   1K-blocks  Used     Avail Capacity  Mounted on
zfstank/home 850525952 58368 850467584     0%    /home
basil# dump -0aLu -f /backup/home-amd64-091006.zfsdump /home
  DUMP: WARNING: Cannot use -L on an unmounted filesystem.
dump: /home: unknown file system

という結果となりました。そりゃ、そうか。素直に zfs sendを使いましょう。

何故dumpにこだわるのかというと、FreeBSDにはchflags (Linuxで言うとchattr)で調整できる拡張ファイル属性があり、これがバックアップ作業に影響することがあるため。例えばrsyncなどでうまく処理出来なかったりします。

というわけで、先日のエントリで無知を晒したわけですが、いつものことなので気にしない分からなくなったらとりあえず寝てから整理する、というのは重要ですね、ということで。

debian/ubuntuでは dump パッケージを導入します。それでも ext2/3 までの対応で、snapshotを取ってダンプする機能があるようには見えませんでした。FreeBSD dump でufs2をダンプしたものを Linux restore でext2/3に移動出来るかは分かりません。他のファイルシステムについては、ext4についてはdump/restore可。xfsはxfsdump/xfsrestoreがある、btrfsはよく分かりません。開発中？

FreeBSD の dump -L ってzfsに対応してますか？

職場PCを新調する機会があり、HDDを増設し、FreeBSD 8.0-RC1 を導入しました。

もののついでに、ちょっとバックアップ体制について見直したのですが、最近は dump(8) に -L オプションなるものがついていて、これを実行すると、丁寧にも一端スナップショットを取得してからdumpする、という振る舞いを見せます。つまりシングルユーザモードに落ちなくても稼働中にdumpが出来るというわけです。これはかなり便利。

ところが、このスナップショットを取得する部分が、ファイルシステムが巨大（100GB以上？）になると途端に処理が重くなります。どうも、ufs2のスナップショットを取得する /sbin/mksnap_ffs に原因があるようです。

http://www.freebsd.org/cgi/query-pr.cgi?pr=111782

600GBくらいのファイルシステムを-Lでダンプしようとするとおかしくなる？(6.x系列)

mksnap_ffs time

シリンダグループの数が多すぎると遅くなる、らしい。

そこで、最近流行の zfs に乗り換えれば、もしかしたらスナップショットの取得も早くなり、dumpも気軽に出来るのかな、と思ったのですが、ここでふと疑問。dumpオプションの-Lは zfs に対応しているのでしょうか？

（バックアップ元のファイルシステムが zfs であるときに、バックアップ先のHDDもzfsにして、zfs send/receive を使うのが筋としては適切、というのは分かるのですが、バックアップ先のHDDがzfsではない、とか、実は未だにテープを愛用している、とか、dump系のシェルスクリプトを書き直すのがちょっとなあ……等といった状況を想定しています。）

dump(8) は -L オプションが実行されると、スナップショットを取得するコマンドを用いるのですが、コードを見ると……
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dump/main.c?rev=1.67.2.1;content-type=text%2Fplain

   char snapname[BUFSIZ], snapcmd[BUFSIZ];

   snprintf(snapname, sizeof snapname, "%s/.snap", mntpt);
   if ((stat(snapname, &sb) < 0) || !S_ISDIR(sb.st_mode)) {
    msg("WARNING: %s %s\n",
        "-L requested but snapshot location",
        snapname);
    msg("         %s: %s\n",
        "is not a directory",
        "dump downgraded, -L ignored");
    snapdump = 0;
   } else {
    snprintf(snapname, sizeof snapname,
        "%s/.snap/dump_snapshot", mntpt);
    snprintf(snapcmd, sizeof snapcmd, "%s %s %s",
        _PATH_MKSNAP_FFS, mntpt, snapname);
    unlink(snapname);
    if (system(snapcmd) != 0)
     errx(X_STARTUP, "Cannot create %s: %s\n",
         snapname, strerror(errno));
    if ((diskfd = open(snapname, O_RDONLY)) < 0) {
     unlink(snapname);
     errx(X_STARTUP, "Cannot open %s: %s\n",
         snapname, strerror(errno));
    }
    unlink(snapname);
    if (fstat(diskfd, &sb) != 0)
     err(X_STARTUP, "%s: stat", snapname);
    spcl.c_date = _time_to_time64(sb.st_mtime);
   }

ここでスナップショットを取得するコマンドが _PATH_MKSNAP_FFSとして定義されているようです。これ、どこにあるのかというと…
http://www.freebsd.org/cgi/cvsweb.cgi/src/include/paths.h?rev=1.28.2.1;content-type=text%2Fplain

#define _PATH_MKSNAP_FFS "/sbin/mksnap_ffs"

これ。で、このソースを見ると、
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mksnap_ffs/mksnap_ffs.c?rev=1.10.2.1;content-type=text%2Fplain

読み切れませんでしたorz

とりあえず、zfsだからといって zfs snapshot を使っているようにも見えず、正直よく分からないのですが、さて、zfsのファイルシステムを dump -L でダンプすることは出来るのでしょうか？　それとも、zfsだと実はわざわざスナップショットを取る必要がない、とか？

追記：後日談を書きました。

電子情報通信学会関連研究会の話題を気軽にtwitterで語るために

twitterのハッシュタグになりそうな名前を提案してみようという企み。使われるかどうかはまあ、おいといて。「信学会」で検索するのが早いとは思うのですが……
（参考： http://www.ieice.org/eng/event_e.html ）

#IEICE_GC 総合大会。IEICE General Conference
#IEICE_SC ソサイエティ大会。IEICE Society Conference
#IEICE_WBS たとえばとして、私がよく行くワイドバンドシステム研究会の例。IEICEの各種研究会は基本的に略記を持つので後ろにそれをつければいい、はず。

twitterのような、発言鮮度？がはっきりしてるツールでは、ハッシュタグに2009とかつける必要はないのかな、と思います。長くなるし２文字か４文字かでまたぶれそうだし。

多分ソサイエティごとに話を切り分けたくなると思うんですが、そこは敢えてハッシュタグを_GCAとかで分けるのではなく、発言中にA-nnとかB-mmなどとして混ぜるほうがよろしいかと思います。大会の話題はなるべく大きく盛り上がるのが大事かなと。

諸般の事情でソサイエティ大会に参加出来ない代わりに、そんなことを思いついたのですが、いかがでしょう？

多分、情報処理学会や電気学会などでも、同様にタグを整理することは出来ると思いますが、私はあまり参加してないので、もう少し詳しい方にお願いしたいです。

ちなみに、個人的にこれどうなの？というのが一つあって……
●平成xx年度 電気・情報関連学会中国支部第n回連合大会
CDや冊子の表紙などを見ると、"rentai20xx" とかが英字略称みたいです。も、もうちょっと何とかならなかったのか……？

（なお、元からさほど発言数が多くない、という本質的な問題については棚上げということで。）