zfs send は破損したファイルがあると使えない2018年04月08日 23時36分06秒

ハードディスクが故障し、新しいディスクが届いたので、復旧作業をしている。

念のためにバックアップを確認してから進めている。他から手に入れたファイルや、既にバックアップとして保存されていたファイルは、別には保持していなかった。その様な優先度の低いファイルも再取得の手間を減らすために、再バックアップを進めている。

その中で、zfs send でうまく行かないファイルシステムがあった。

$ zfs list -r -t all scratch/media
NAME                   USED  AVAIL  REFER  MOUNTPOINT
scratch/media          281G  1.04T   280G  /mnt/zfs/media
scratch/media@2016     407K      -   143G  -
scratch/media@2017     150M      -   270G  -
scratch/media@2018     279K      -   279G  -
$ zfs send -v scratch/media@2016 > /dev/null
full send of scratch/media@2016 estimated size is 144G
total estimated size is 144G
TIME        SENT   SNAPSHOT
14:25:42   70.2K   scratch/media@2016
14:25:43   25.8M   scratch/media@2016
14:25:44   58.5M   scratch/media@2016
14:25:45   62.1M   scratch/media@2016
...
14:26:32   1.44G   scratch/media@2016
14:26:33   1.46G   scratch/media@2016
14:26:34   1.48G   scratch/media@2016
14:26:35   1.50G   scratch/media@2016
warning: cannot send 'scratch/media@2016': Input/output error
途中で止まっている。気がかりは数日前には既にあった。zpool で確認すると、このスナップショットには壊れたファイルがある。
$ zpool status -v
  pool: scratch
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilvered 465G in 36h43m with 112 errors on Sat Apr  7 12:37:58 2018
config:

        NAME                                    STATE     READ WRITE CKSUM
        zfs                                     DEGRADED     1     0   453
          raidz1-0                              DEGRADED     1     0 1.62K
            gpt/zfs1                            ONLINE       0     0     0
            gpt/zfs2                            ONLINE       2     0     0  (resilvering)
ering)
            gpt/zfs3                            ONLINE       1     0     0  (resilvering)
            15470053991832379715                UNAVAIL      0     0     0  was
/dev/gpt/zfs4

errors: Permanent errors have been detected in the following files:

        scratch/media@2017:/freebsd/FreeBSD-10.2-RELEASE-i386-disc1.iso
        /mnt/scratch/media/freebsd/FreeBSD-11.1-RELEASE-i386-disc1.iso
        <0x202>:<0x2a>
        <0x2a>:<0x3f>
        <0x2a>:<0x49>
        <0x2a>:<0x57>

特に復旧できなくても大きな問題ではないので、rsync でファイルをコピーした。

実は、これ以外にも壊れていたファイルがあって、こまめにスナップショットを取っていたファイルシステムは難を逃れることが出来た。zfs スナップショットはある程度こまめに、そして各スナップショットのサイズを考慮して保持しておいた方が、復旧に楽だ。

上の例では、scratch/media の FreeBSD 11.1 RELEASE の ISO ファイルは壊れていた。また、media@2017 のスナップショットも壊れている。ただ、media@2017 は他の場所に既に、zfs send のバックアップが保存されていた。そのため、FreeBSD-11.1-RELEASE-i386-disc1.iso のファイルを消し、media@2018_04 のスナップショットを取った。

$ zfs send -i 2017 scratch/media@2018_04
幸いにも、この差分には壊れたファイルは存在しない。FreeBSD-10.2-RELEASE-i386-disc1.iso はスナップショット上では壊れているが、送られる必要が無いからだ。

これを契機に、zfs スナップショットは 50GB ぐらい毎に保持する事にした。こうすることで、ファイルが破損しても zfs send で送れるスナップショットが残る可能性があがる。また、一つのスナップショットが大きくなると、転送に時間が掛かるのも一つの理由だ。

zpool status -v で見られる変な名前のファイル2018年04月08日 13時01分12秒

zpool status で zfs のプールの状態を表示できる。zpool status だけなら一般ユーザでも実行できる。さらに、-v を付けたし、zpool status -v を行うと損傷を受けているファイルの一覧が見られる。こちらは特権ユーザの権限が必要になる。
$ zpool status -v
  pool: scratch
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Apr  5 23:54:13 2018
        961G scanned out of 2.35T at 11.4M/s, 36h5m to go
        458G resilvered, 39.83% done
config:


        NAME                                    STATE     READ WRITE CKSUM
        zfs                                     DEGRADED     1     0   453
          raidz1-0                              DEGRADED     1     0 1.62K
            gpt/zfs1                            ONLINE       0     0     0
            gpt/zfs2                            ONLINE       2     0     0  (resilvering)
ering)
            gpt/zfs3                            ONLINE       1     0     0  (resilvering)
            replacing-3                         DEGRADED     2     0     0
              15470053991832379715              UNAVAIL      0     0     0  was
/dev/gpt/zfs4
              gpt/zfs5                          ONLINE       2     0     0  (resilvering)

errors: Permanent errors have been detected in the following files:

        scratch/media@2017:/freebsd/FreeBSD-10.2-RELEASE-i386-disc1.iso
        /mnt/scratch/media/freebsd/FreeBSD-11.1-RELEASE-i386-disc1.iso
        <0x202>:<0x2a>
        <0x2a>:<0x3f>
        <0x2a>:<0x49>
        <0x2a>:<0x57>

これを見れば、幾つか気が付くと思うが、スナップショットのファイルが損傷した場合と、スナップショットが取られていないファイルが損傷のファイルパスが若干異なるようだ。

そして、もう一つ括弧に囲まれた不思議な文字の羅列がある。これは、損傷が確認されたが既に消されているファイルになる。ファイルを削除したり、スナップショットを削除しても、zpool clear を行わないとそのまま残る様だ。

スナップショットに入っていると、恐らく、それ以降の全てのコピーが損傷している。当該ファイルが入っているスナップショットを全て消すと、ファイル名ではなく、この括弧連弾が表示される。スナップショットに入っていないファイルだと、rm で消すと、括弧連弾になる。

zpool replace のディスク交換を中断2018年04月08日 07時57分21秒

ZFS でディスクを交換するときは、zpool replace pool old-device new-device で始める。そうすると、resilver が始まり、データの移行が進められる。

何らかの理由により、ディスクの交換を中断したいときがある。そんな時は、zpool detach pool new-deviceで中断できる。

$ zpool status
  pool: scratch
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Apr  5 23:54:13 2018
        959G scanned out of 2.35T at 11.4M/s, 36h6m to go
        458G resilvered, 39.83% done
config:


        NAME                                    STATE     READ WRITE CKSUM
        zfs                                     DEGRADED     1     0   453
          raidz1-0                              DEGRADED     1     0 1.62K
            gpt/zfs1                            ONLINE       0     0     0
            replacing-1                         ONLINE       0     0   106
              gpt/zfs2                          ONLINE       2     0     0  (resilvering)
              gpt/zfs6                          ONLINE       0     0     0  (resilvering)
            gpt/zfs3                            ONLINE       1     0     0  (resilvering)
            replacing-3                         DEGRADED     2     0     0
              15470053991832379715              UNAVAIL      0     0     0  was
/dev/gpt/zfs4
              gpt/zfs5                          ONLINE       2     0     0  (resilvering)


$ zpool detach scratch /dev/gpt/zfs6
$ zpool status
  pool: scratch
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Apr  5 23:54:13 2018
        961G scanned out of 2.35T at 11.4M/s, 36h5m to go
        458G resilvered, 39.83% done
config:


        NAME                                    STATE     READ WRITE CKSUM
        zfs                                     DEGRADED     1     0   453
          raidz1-0                              DEGRADED     1     0 1.62K
            gpt/zfs1                            ONLINE       0     0     0
            gpt/zfs2                            ONLINE       2     0     0  (resilvering)
ering)
            gpt/zfs3                            ONLINE       1     0     0  (resilvering)
            replacing-3                         DEGRADED     2     0     0
              15470053991832379715              UNAVAIL      0     0     0  was
/dev/gpt/zfs4
              gpt/zfs5                          ONLINE       2     0     0  (resilvering)
resilver が発生していたディスクはそのまま作業が進められるようだ。

東芝の Canvio Plus 750GB が故障した2018年04月01日 14時36分11秒

東芝の Canvio Plus 750GB External USB 2.0 Portable Hard Drive が故障直前の様だ。いきなり FreeBSD が panic を起こした。 fsck を試すと、読めないセクタがある。

東芝の Canvio Connect II を購入したのは 2016年02月18日 となっている。これよりも大分前から使っていたが、購入した時期はまったく覚えていない。私の両親は、電器製品には必ずと言って程購入日を本体に書き込んでいた。子供の頃はなぜそんな事をするのか不思議だったのを思い出した。

現状では、この外付けディスクを繋ぐだけで、cam のエラーが連発する。そのまま五分ぐらいでも放置しておくと安定してくるようで、一旦cam エラーは止まる。

このディスクには ufs と zfs が納められている。fsck がファイルシステムの復旧を出来ないので、ufs は致命的な損傷を受けている模様。zfs は raid-z の一部なのだが、今のところは zfs を壊さないように、ファイルシステムは外してある。

ufs は実は私のホームディレクトリ。取り敢えず、この ufs の復旧は急を要す。また、写真なども多いので、新しい外付けのディスクは注文した。

次回

vm.kmem_size_max が大きすぎても ZFS が動かない2017年12月21日 13時05分20秒

vm.kmem_size_max を大きくしすぎても ZFS が動かないようだ。メモリが 2GB の古い機種の /boot/loader.conf で
vm.kmem_size_max="1024m"
と設定してた。

時おり、以下の様なエラーを出して、操作不能になっていた。この状態になると、ファイルシステム自体にはダメージは無いが、システムの状態がおかしくなり再起動が必要になる。

taskqueue_start_threads: kthread_add(zio_free_issue_6): error 12vm_thread_new: kstack allocation failed
taskqueue_start_threads: kthread_add(zio_free_issue_7): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_free_intr): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_claim_issue): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_claim_intr): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_ioctl_issue): error 12vm_thread_new: kstack allocation failed
taskqueue_start_threads: kthread_add(zio_ioctl_intr): error 12vm_thread_new: kstack allocation failed
そこで、/boot/loader.conf でメモリの割り当てを半分にしてみた。
vm.kmem_size_max="512m"
この後は、もっとたくさんの zpool や zfs を扱える様になって、以前の様に、操作に失敗する事は無くなったようだ。

ただし、以前は 300MB まで増えていた ARC キャッシュが 50MB 前後の利用量に落されているようだ。

Too big vm.kmem_size_max results process/thread creation errors2017年11月30日 13時26分58秒

Over-allocation of vm.kmem_size_max results in system instabilities. I have set vm.kmem_size_max to 1GB for i386 with 2GB of RAM.
vm.kmem_size_max="1024m"

I experiences kernel memory running out such as thread creation failures, unable to import multiple zpools, and process creation failures. seamonkey/firefox tends to fail to create a tab due to thread creation errors.

taskqueue_start_threads: kthread_add(zio_free_issue_6): error 12vm_thread_new: kstack allocation failed
taskqueue_start_threads: kthread_add(zio_free_issue_7): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_free_intr): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_claim_issue): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_claim_intr): error 12vm_thread_new: kstack allocation failed
kthread_add(zio_ioctl_issue): error 12vm_thread_new: kstack allocation failed
taskqueue_start_threads: kthread_add(zio_ioctl_intr): error 12vm_thread_new: kstack allocation failed

I reduced the size in /boot/loader.conf

vm.kmem_size_max="512m"
After this adjustments, I am be able to import multiple zpools, stopped seeing process and thread creation errors.

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 は再構築が一番。