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 が発生していたディスクはそのまま作業が進められるようだ。

Toshiba Canvio Basics 3TB を購入2018年04月06日 13時36分07秒

Canvio Plus 750GB が故障したので、交換用に Toshiba Canvio Basics 3TB を購入。

故障した日に値段を調べたら、3TB で 80 ドル。4TB で 100 ドルで売っていた。探していたのはポータブル型。4TB の方がバイトあたりの単価が安い。深夜遅くなったので、次の日に注文することにした。

その次の日に何と、丁度見ていた 3TB の外付けディスクが日替わりセールになっていて、70 ドルに。昨日は 4TB は大きすぎて迷っていたので、そちらに決めた。そして注文したのが週末。それが数日前の夜に届いていた。

早速 FreeBSD 11.1-RELEASE に繋いでみる。dmesg はこうなった。

da1 at umass-sim1 bus 1 scbus4 target 0 lun 0
da1:  Fixed Direct Access SPC-4 SCSI device
da1: Serial Number 20180127xxxxxxF
da1: 40.000MB/s transfers
da1: 2861588MB (5860533164 512 byte sectors)
da1: quirks=0x2
シリアルナンバーは日付を使っている様だ。USB3 だが、古いHP Pavilion dv6425us と同じ時期に買った HP Pavilion dv6426us なので、ホスト側はスピードは出ないのは折り込み済み。

前回。

FreeBSD の SA が二つに ERRTA が二つ2018年04月05日 11時36分27秒

FreeBSD-SA-18:04.vt.asc は vt コンソール。10 系では設定により、11 系ではデフォルトで有効になった。フォントの設定のチェックが甘くて、意図せずにカーネルメモリをコンソールに出力してしまうバグ。10 系では sc コンソールを使っていると影響は無い。

FreeBSD-SA-18:05.ipsec.asc の対象はサポートされている全てのリリース。10 系と 11 系になる。IPSec のヘッダの長さに 0 を指定されていると、カーネルがクラッシュする。

FreeBSD-EN-18:03.tzdata.asc は夏時間の適応データの更新なので、自ずから全てのリリースが対象

FreeBSD-EN-18:04.mem.ascの対象も全てのリリース。こちらは、HighPoint ディスクコントローラの問題。 hpt27xx(4)、hptnr(4)、 hptrr(4) のドライバのメモリの初期化に問題があり、カーネルデータがユーザ領域に洩れてしまうことがある。

Canvio Plus 750GB の FreeBSD ufs をまず復旧2018年04月02日 13時22分29秒

東芝の Canvio Plus 750GB External USB 2.0 Portable Hard Drive が誤動作を起こし始めた。新しいディスクは注文した。fsck の直せない ufs の復旧が第一の課題。

このディスクは ufs と zfs で使っている。zfs は raid-z の一部。こちらには大量の写真や家族の動画が入っている。これは、新しいハードディスクを購入してから、zpool replace で交換する必要があるので、こちらの復旧作業は後回し。

この ufs はホームディレクトリとして利用している一番重要なデータ。こちらは、時おり ufs_copy でディスクをファイルシステム毎バックアップしている。ディスクは何度も移り変わっているが、既に十年、十五年以上前に作ったファイルシステムなので、29GB のみ。作成当時はディスク一台で、全てのファイルが入っていたが、既に写真などの大容量は別途保管して、それこそ日頃のメールやブラウザの履歴などが入っている。zfs のバックアップに週に一度ぐらい気の向いたときにバックアップを取っている。

別の zfs には二、三日前に取ったホームディレクトリのバックアップはある。ただ、税金申告の期限が迫っているので、あれこれ更新していたものがあるので、出来れば故障したディスクから復旧したい。手元を漁ると I-O DATA の HDPS-U に 30GB のスペースがすぐに融通できるのでそれを使う事にした。これは、実家に帰っていた時に、写真が入りきらなくなった時に、譲り受けた機械。父の手書きで、2009 年と日付が書いてある。

ディスクの復旧は recoverdisk。dd よりも優れている。recover_disk はファイルブロックサイズを大きめで始める。エラーがあるとエラー箇所を一度飛ばし、そのままコピーを終端まで終らせる。その後で、ブロックサイズを小さくして、エラーのあった箇所を再試行する。-w オプションを付けると、経過とエラー箇所をファイルに書き出す。

$ recoverdisk -w home.err /dev/label/home.eli /dev/da0s2
最終的に読めなかったブロックは六つぐらい。fsck が先に進めないので、このブロックはシステム情報が管理されているのだろう。その後、壊れたディスクを読み出しのみの mount -r でマウントを試みた。
$ mount -r /dev/label/home.eli /home
これでもマウント出来ない。

このファイルシステムは完全に壊れてしまった様だ。直せないのなら、更に壊しても、新たに失うものは無いので、強制復旧を試みる。そして、ufs のメタデータだったとの推測から、古いディスクイメージからこの故障セクタのみを写すという荒技を試すことにした。

$ mdconfig -a -t vnode -f /mnt/backup/20180301/home.ufs -oreadonly
md1
$ recoverdisk -r home.err /dev/md1 /dev/da0s2
$ fsck_ufs -y /dev/da0s2
$ fsck_ufs -y /dev/da0s2
$ mount -r /dev/da0s2 /home
mdconfig で古いディスクイメージを読み出しのみで設定する。ファイルのままでも処理できるが、間違えた時にダメージを回避するため md デバイスを利用。さっきの recoverdisk に home.err を渡して、破損セクタだけをコピーする。fsck を動かしたら、ファイルシステムを修正したので、再度 fsck を行うように指示された。

この後、mount は成功し、zfs のバックアップを元に復旧度合を確かめた。特にファイルの損失もなく、こちらの方が新しいので、ディスクからの普及には成功したとの結論に至った。

前回次回

東芝の 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 の復旧は急を要す。また、写真なども多いので、新しい外付けのディスクは注文した。

次回

VMware Fusion で仮想マシンを複製することによって、解放されていないディスクスペースを取り戻す2018年03月22日 11時30分08秒

最近、MacBook にて、VMware Fusion を使っている。幾つかの仮想マシンがあるが、その一つに FreeBSD を入れて、ZFS 等で遊んでいた。

400GB 程あるはずの、ハードドライブの容量が圧迫されたと言われて VMware が動作を中断して、プロンプト待ちを起こすことが出てきた。Mac 上のファイルを消しても消しても、すぐにディスクの容量が足りないと警告される。

さて、VMware の動作に問題がありそうなので、じっくりと見はじめた。最初に気が付いたのが、VMBoundle ファイルが異常に大きいこと。25 GB の仮想ハードドライブを二つに、50 GB の仮想ハードドライブを一つ作っていて、FreeBSD 上で見ると半分以下しか使われていない。VMBoundle ファイルが、170 GB もあるのだ。スナップショットを取ったり消したり、ディスクを作成したり、削除したりを繰り返したりもした。

今回の容量の異常に関し、全てのスナップショットを消してみた。それでも 170GB も物理ディスクを占有していたのである。ディスクのクリーンナップ等を行っても一向に改善しない。

一つ気が付いたのは既存のディスクの追加を選ぶと、見覚えの無いディクスが沢山出てくるのである。そこで、VMware のファイル管理に問題があると結論に達した。恐らく、電源が落ちてしまったり、MacOS がクラッシュしたときに、VMware のファイル管理に不整合が出来てしまったのだと。

仕方がないので、VMware の「Create Full Clone」を使って、複製し古いコピーを捨てることにした。「Create Full Clone」を実行すると、170 GB のディスク占有量の仮想マシンから、50GB のディスク占有量の仮想マシンが出来た。割り当てている仮想ディスクの総量は 100GB で利用率は半分以下。複製の結果は妥当に見えた。

その後、数回の起動点検と確認を行って、問題なく複製できているのを確信した後に、余分な 170GB のファイルを消して、VMware のディスク圧迫バグから回避することが出来た。

FreeBSD の Speculative Execution Vulnerabilities の SA2018年03月15日 13時10分27秒

FreeBSD-SA-18:03.speculative_execution のパッチが公開された。今回の修正は FreeBSD 11.1-RELEASE の amd64 と i386 が対象のようだ。patch を見ると、カーネルに加えて、cpucontrol が修正されている。10 系の修正は後で用意されるとのこと。

ウェブブラウザー等越しで、信頼できないコードがカーネルメモリを読めてしまう。通称 Meltdown と言われている問題の修正だ。

結構前に FreeBSD 11.2-RELEASE のスケジュールが出されてた2018年03月11日 23時22分54秒

FreeBSD 11.2-RELEASE の予定が更新されている。最近は、11.1-STABLE と 12-CURRENT をあれこれ使っているので、そのまま追いかけを続けるつもり。
Action Expected Actual Description
Initial release schedule announcement - 12 February 2018 Release Engineers send announcement email to developers with a rough schedule.
Release schedule reminder 16 March 2018 - Release Engineers send reminder announcement e-mail to developers with updated schedule.
Code slush begins 20 April 2018 - Release Engineers announce that all further commits to the stable/11 branch will not require explicit approval, however new features should be avoided.
Code freeze begins 4 May 2018 - Release Engineers announce that all further commits to the stable/11 branch will require explicit approval. Certain blanket approvals will be granted for narrow areas of development, documentation improvements, etc.
BETA1 builds begin 11 May 2018 - First beta test snapshot.
BETA2 builds begin 18 May 2018 - Second beta test snapshot.
BETA3 builds begin * 25 May 2018 - Third beta test snapshot.
releng/11.2 branch 1 June 2018 - Subversion branch created; future release engineering proceeds on this branch.
RC1 builds begin 1 June 2018 - First release candidate.
stable/11 thaw 3 June 2018 - The code freeze on the stable/11 branch is lifted.
RC2 builds begin 8 June 2018 - Second release candidate.
RC3 builds begin * 15 June 2018 - Third release candidate.
RELEASE builds begin 22 June 2018 - 11.2-RELEASE builds begin.
RELEASE announcement 27 June 2018 - 11.2-RELEASE press release.
Turn over to the secteam - - releng/11.2 branch is handed over to the FreeBSD Security Officer Team in one or two weeks after the announcement.