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 -
途中で止まっている。気がかりは数日前には既にあった。zpool で確認すると、このスナップショットには壊れたファイルがある。
$ 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
特に復旧できなくても大きな問題ではないので、rsync でファイルをコピーした。
$ 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>
実は、これ以外にも壊れていたファイルがあって、こまめにスナップショットを取っていたファイルシステムは難を逃れることが出来た。zfs スナップショットはある程度こまめに、そして各スナップショットのサイズを考慮して保持しておいた方が、復旧に楽だ。
上の例では、scratch/media の FreeBSD 11.1 RELEASE の ISO ファイルは壊れていた。また、media@2017 のスナップショットも壊れている。ただ、media@2017 は他の場所に既に、zfs send のバックアップが保存されていた。そのため、FreeBSD-11.1-RELEASE-i386-disc1.iso のファイルを消し、media@2018_04 のスナップショットを取った。
幸いにも、この差分には壊れたファイルは存在しない。FreeBSD-10.2-RELEASE-i386-disc1.iso はスナップショット上では壊れているが、送られる必要が無いからだ。
$ zfs send -i 2017 scratch/media@2018_04
これを契機に、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秒
zpool replace pool old-device new-device で始める。そうすると、resilver が始まり、データの移行が進められる。
何らかの理由により、ディスクの交換を中断したいときがある。そんな時は、zpool detach pool new-deviceで中断できる。
resilver が発生していたディスクはそのまま作業が進められるようだ。
$ 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)
Toshiba Canvio Basics 3TB を購入 ― 2018年04月06日 13時36分07秒
故障した日に値段を調べたら、3TB で 80 ドル。4TB で 100 ドルで売っていた。探していたのはポータブル型。4TB の方がバイトあたりの単価が安い。深夜遅くなったので、次の日に注文することにした。
その次の日に何と、丁度見ていた 3TB の外付けディスクが日替わりセールになっていて、70 ドルに。昨日は 4TB は大きすぎて迷っていたので、そちらに決めた。そして注文したのが週末。それが数日前の夜に届いていた。
早速 FreeBSD 11.1-RELEASE に繋いでみる。dmesg はこうなった。
シリアルナンバーは日付を使っている様だ。USB3 だが、古いHP Pavilion dv6425us と同じ時期に買った HP Pavilion dv6426us なので、ホスト側はスピードは出ないのは折り込み済み。
da1 at umass-sim1 bus 1 scbus4 target 0 lun 0
da1:
FreeBSD の SA が二つに ERRTA が二つ ― 2018年04月05日 11時36分27秒
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秒
このディスクは 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 オプションを付けると、経過とエラー箇所をファイルに書き出す。
最終的に読めなかったブロックは六つぐらい。fsck が先に進めないので、このブロックはシステム情報が管理されているのだろう。その後、壊れたディスクを読み出しのみの mount -r でマウントを試みた。
$ recoverdisk -w home.err /dev/label/home.eli /dev/da0s2
これでもマウント出来ない。
$ mount -r /dev/label/home.eli /home
このファイルシステムは完全に壊れてしまった様だ。直せないのなら、更に壊しても、新たに失うものは無いので、強制復旧を試みる。そして、ufs のメタデータだったとの推測から、古いディスクイメージからこの故障セクタのみを写すという荒技を試すことにした。
mdconfig で古いディスクイメージを読み出しのみで設定する。ファイルのままでも処理できるが、間違えた時にダメージを回避するため md デバイスを利用。さっきの recoverdisk に home.err を渡して、破損セクタだけをコピーする。fsck を動かしたら、ファイルシステムを修正したので、再度 fsck を行うように指示された。
$ 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
この後、mount は成功し、zfs のバックアップを元に復旧度合を確かめた。特にファイルの損失もなく、こちらの方が新しいので、ディスクからの普及には成功したとの結論に至った。
東芝の Canvio Plus 750GB が故障した ― 2018年04月01日 14時36分11秒
東芝の 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秒
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 の SA ― 2018年03月15日 13時10分27秒
ウェブブラウザー等越しで、信頼できないコードがカーネルメモリを読めてしまう。通称 Meltdown と言われている問題の修正だ。
結構前に FreeBSD 11.2-RELEASE のスケジュールが出されてた ― 2018年03月11日 23時22分54秒
| 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. |
最近のコメント