zfs send -R を受け取るのは zfs receive -d が良さそうだ2017年08月14日 12時23分46秒

ZFS に保存している写真のファイルシステムをバックアップすることにした。
zfs list -t all
...
zfs/pict                 304G  92.4G   301G  /mnt/zfs/pict
zfs/pict@2017_02_26     1.15G      -   283G  -
zfs/pict@2017_07_05     1.36G      -   299G  -
zfs/pict@2017_08_13     11.6K      -   301G  -
ファイルに間違って重複があり、差分のみをファイルから取り除いた。そのため、スナップショットに元の巨大な重複ファイルが野持ってしまったので、昨年までのスナップショットを消した。そのため、スナップショットの数は少ない。差分で複製するとなると、スナップショットが少ないと、不便だ。

スナップショット名を指定した形で試したら失敗した。

$ zfs send -R zfs/pict@2017_08_13 | zfs receive bkup/camera@2017_08_13

 cannot receive: cannot specify snapshot name for multi-snapshot stream
 warning: cannot send 'zfs/pict@2017_02_26': Broken pipe
 warning: cannot send 'zfs/pict@2017_07_05': Broken pipe
 warning: cannot send 'zfs/pict@2017_08_13': Broken pipe
そこで、receive の -d オプションを利用。
$ zfs send -R zfs/pict@2017_08_13 | zfs receive -d -v bkup/camera
これで、無事に複製できたようだ。send と receive を同時に行う場合は、receive 側に -v を付けた方が見やすくエラーも分かりやすい。

ZFS を NFS で export する2016年06月03日 12時35分29秒

FreeBSD 上の ZFS を NFS で公開する方法は幾つかあるようだ。zfs share を用いた方法から、/etc/export のみで行う古典的な方法などがある。

一番簡単なのは古典的な方法。/etc/export に UFS と同じように記述する。NFS v3 を用いての記述例。以下の zfs はいわゆる legacy mount 形式を使っている。

$ cat /etc/export
/mnt/zfs -alldirs -network 10.0.0.0/8
$ sh /etc/rc.d/nfsd onestart
/mnt/zfs に zfs がマウントされている。ロックなどが必要でなければ、nfsd のみ起動。
$ mount | grep zfs
zfs on /mnt/zfs (zfs, NFS exported, local, noatime, nfsv4acls)

ZFS こそバックアップが重要2016年03月29日 09時35分22秒

先日の不慮の事故にて zpool を壊した時に、破損した zpool は諦めて再構築した方が良いとの結論に達した。

スナップショットなどの便利な機能がある為に、バックアップ代りになるとの意見もちらほら見る。軽微な損傷には滅法強いが、大きな破損からの回復はやや難しい。それゆえ、今回は逆に ZFS こそバックアップが重要なのを感じた。

今回は特にディスクを交換した直後だったので、各種バックアップはかなり揃っていた。破損しても、そこまで重要では無いファイルは、別途のバックアップは無かったが、既に古いバックアップのファイルなので失ってもあまり被害が無いものばかり。今後は少しこまめに差分バックアップを取っておこうと思う。

zpool の修復を試みての結論2016年03月25日 12時36分11秒

ここ数日の間、zpool が破損して resilver を繰り返していたので、復旧を試みていた。

HRS's Web Page の ZFS のトラブル続きは結構古いが、ここが細かな説明などでも相変わらず的を得ていて、参考になる。

UFS では、fsck でかなりの問題は解決できて、それこそ書き込み中のファイルでもない限りは他所への影響は限定的だった。

ZFS では、派手な失敗を犯すと派手に壊れていくようだ。zpool status -v で影響のあったファイルを削除し、エラーが出たディレクトリを別に退避したり、バックアップのあるファイルの削除を行ったりと、回復を試みた。

最終的には、resilier を繰り返すよりも、バックアップをして、zpool を destroy で一度破壊して、再構築した方が早かった。致命的なダメージを与えた zpool は下手に、修復を試みるよりもさっさと諦めて、作り直した方が手っ取り早く、また安全。

七年近く使っていた zpool だったので、プール自体はそのまま保持しようと思ったのと、折角なので zpool を観察してみたかったのもある。そこでの最終結論は上記の通り。派手に壊れた zpool は再構築が一番。

kmem_size は maxssiz と maxdsiz に影響される2016年03月24日 12時13分24秒

i386 で ZFS を使うと、vm.kmem_size を大きく割り当ててカーネルメモリを増やす必要がある。zfs モジュールを読み込むと 512MB は最低でも割り当てるようにと表示される。

最近気が付いたのだが、kern.maxdsiz と kern.maxssiz が vm.kmem_size に影響するようだ。これらを初期値よりも多めに割り当てていた。残念ながら何故大きくしていたのかを思い出せない。恐らく、wine の為だったのだと思うのだが…。

どちらがどれだけ影響するかは調べていないが、これらの設定を削除した後に、vm.kmem_size がより大きく割り当てられる様になり、それに伴って vfs.zfs.arc_max も大きく設定出来るようになった。

geli と ZFS で 4k ブロックサイズ2016年03月23日 11時49分49秒

geli は FreeBSD での暗号化デバイス。ZFS と共にも用いると思う。ZFS を利用するときには 4K ブロックにて読み書きをして負荷を減らすと推奨する事も多い。大概は、geom_nop を用いて一時的にデバイスのブロックサイズを 4096 バイトと偽って zpool を作成する。

geli はそれ自体でブロックサイズを調整出来る。init 時に -s オプションでバイト数を指定できる。ZFS を 4k ブロックにするためには geli init -s 4096 とすれば良い。

zfs の resilver が繰り返した時の対処方法2016年03月17日 10時59分48秒

先日の USB 端子が抜けた時に zfs を壊したようだ。ZFS が何度も resilver を起動し直すが、途中で終了し再開してしまう。まさに無限ループの状態。今回は、破壊されたファイルに相当する。現在利用中の OS は FreeBSD 10.2-RELEASE と FreeBSD 11-CURRENT だ。

再起動したりして、OS や resilver をやり直すと、エラーのあるファイルが表示されなくなるようだ。ファイルが破損していると、zpool status -v で破損しているデータが表示される。これをメモを取るなり、ファイルに書き出すなりをしておいた方がいい。

errors: Permanent errors have been detected in the following files:
にて表示されると破損済みで、修復は不可能な模様。バックアップから復帰するのみだ。

この表示を見た後に、ディスクが反応していない、OS が反応していないなどの理由で強制再起動をかけると、次回の resilver が破損したファイルを正しく見付けられず、そして、resilver の繰り返しに陥るみたいだ。

このままにしておくと ZFS 自体は一応使えるが、ディスクは resilver が掛かりっぱなし。結局のところ、これを止めるにはファイルを削除するしかないようだ。

スナップショットも痛んだようで、更新分をバックアップに移動。zfs destroy で一時的に削除し、バックアップから戻すことを繰り返えした。これで、一部の問題部分が削除されるので、resilver の進行度が以前よりも進むようになっている。まだ少し壊れているファイルがあるようで、また resilver が掛かっているところだ。

FreeBSD の USB 接続の注意点2016年03月16日 09時22分42秒

FreeBSD で外付けのハードディスクを幾つか使っている。そのなかで起きた問題は大きく分けて三つ。
  1. USB を抜く時に隣の線を動かして、一時的に断線する。
  2. 外付けの電源が抜けてしまい停止する。
  3. USB を抜いた時にバスのスキャンが掛かり、デバイスが一時的に外れてしまう。

最初のは人為的なミス。気を付けはしているが、どうしても避けられない。動作中に機械を動かしたり、接続し直したりするときに間違って起きたり、スイッチが意図に反して切れてしまったりする。

三つ目は抜き差しを繰り返したり、二台、三台と USB 機器を接続していると起きるようだ。必ず起きるわけでは無いが、起きると困るので、ファイルを移動しているときなどは慎重になるようになった。

これらで、ZFS も UFS も落したことがあるが、UFS の方が障害時に安全で被害も少ないのが個人的な印象。ただ、UFS は一デバイスに収まっているので、被害が限定的になりやすいのも事実。UFS は作業中のファイルだけが壊れ、時間こそ掛かるが、fsck でほぼ事足りる。ZFS は柔軟で拡張性も高いが、raidz でも複数のデバイスが一気に落ちると、自動修正の所為で逆に脆いようだ。デバイスが一気に消えて、一部の繋がっているデバイスで更に無理をしようとするので、触っていないファイルまで被害が及んだりする。その後の scrub 等が厄介だ。

個人的な利用の範囲なので、それなりに偏った環境だとは思う。だが、逆にスナップショットや raidz で、複数の履歴を保持しているZFS でこそバックアップをしっかり取っておきたいと思う。

zfs send でスナップショットを一気に送る2016年02月29日 13時33分29秒

zfs send で一気に送ったファイルシステムもあれば、全てのスナップショットを複製したい場合もある。そんな時に使うのが大文字の -I オプション。二つの間にあるスナップショットの全てを一度に移動できる。ただし、これは必ず二つスナップショットを指定しないといけないので、最初のスナップショットは別に送る必要がありそうだ。当該機は、FreeBSD 10.2-RELEASE。

年に一つ、二つ保存しているファイルシステムをこのように送れる。-n を使って、試行。

# zfs send -n -v -I 2010_02_27 zfs/export@2015_11_23
send from @2010_02_27 to zfs/export@2012_07_22 estimated size is 61.2G
send from @2012_07_22 to zfs/export@2013_11_21 estimated size is 15.3G
send from @2013_11_21 to zfs/export@2014_07_20 estimated size is 9.17G
send from @2014_07_20 to zfs/export@2014_11_21 estimated size is 1.71G
send from @2014_11_21 to zfs/export@2015_02_24 estimated size is 2.25G
send from @2015_02_24 to zfs/export@2015_07_20 estimated size is 3.79G
send from @2015_07_20 to zfs/export@2015_11_23 estimated size is 2.44G
total estimated size is 95.8G

実際に送るときは、二段回式。

# zfs send zfs/export@2010_02_27 | zfs receive bkup/export@2010_02_27
# zfs send -I 2010_02_27 zfs/export@2015_11_23 | zfs receive bkup/export
一つ目のコマンドと、二つ目のコマンドでは receive の方の引数が、若干変わる。

FreeBSD 11-CURRENT の zpool iostat は表示毎にデバイスを探す2016年02月26日 19時40分44秒

FreeBSD 11-CURRENT の zpool iostat でエラーが出るで、利用を控えていたが、幾つかの複合的な原因があるようだ。

11-CURRENT の zpool iostat は、表示をする度に接続していないプールを探しにいくようだ。先日、二つの ZFS のプールをまとめたのだが、それ以前は接続口の関係で、大体片方のプールしか接続していなかった。zpool export で外すことなく、zfs mount から外してマウントしていないだけの状態だった。

11-CURRENT 以前の zpool iostat ではその様な状態でも問題なく動作する。二つのプールのうちの一つのみを表示。

プールを統合した後から zpool iostat のエラーは出なくなった。そして、とくに zpool iostat 1 をした時の、毎秒起こるデバイスへのへのアクセスが無くなった。そして、zpool iostat も問題なく表示される。

この事から察するに、以前の zpool iostat は見付からないデバイスを探し続けることは無かったが、11-CURRENT からは表示の度に探しにいくようになったようだ。