badsect を行い、 fsck をかける2017年05月20日 13時21分48秒

折角なので、badsect を試してみる。このファイルシステムは、書き込み用にマウント出来ないので、newfs をした。もしかしたら、-f で強制的に、マウントして試しても良かったのかも知れない。

まず、ディレクトリを作る。そして、badsect にディレクトリ名と fsck にて問題があるとされたセクタを指定する。

# mkdir .BAD
# badsect .BAD 20468153 20468154
Don't forget to run ``fsck /dev/ada0s2e''
初めて使うので知らなかったが、fsck を行うように出た。

折角なので、各種コマンドがどの様にファイルを見つけるか実験。

# find .BAD/
.BAD/
.BAD/20468153
.BAD/20468154
# ls -l .BAD/
ls: 20468153: Bad file descriptor
ls: 20468154: Bad file descriptor
total 0
# file .BAD/*
file: No match.
Don't forget to run ``fsck /dev/ada0s2e''
ls は認識するが、表示形式が他のファイルとは全く違う。find はファイルとして見つけた。file はファイルの存在自体を見つけられていない。

次に fsck をかける。

# fsck_ufs -y /dev/ada0s2e
** /dev/ada0s2e
** Last Mounted on /usr/local
** Phase 1 - Check Blocks and Sizes

HOLD BAD BLOCK? yes

INCORRECT BLOCK COUNT I=1219937 (0 should be 8)
CORRECT? yes


HOLD BAD BLOCK? yes

2558519 DUP I=1219938
UNEXPECTED SOFT UPDATE INCONSISTENCY

INCORRECT BLOCK COUNT I=1219938 (0 should be 8)
CORRECT? yes

INTERNAL ERROR: dups with softupdates
UNEXPECTED SOFT UPDATE INCONSISTENCY
** Phase 1b - Rescan For More DUPS
2558519 DUP I=1219937
UNEXPECTED SOFT UPDATE INCONSISTENCY

** Phase 2 - Check Pathnames
DUP/BAD  I=1219937  OWNER=root MODE=100600
SIZE=4096 MTIME=Jun 16 23:23 2017 
FILE=/.BAD/20468153

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? yes

DUP/BAD  I=1219938  OWNER=root MODE=100600
SIZE=4096 MTIME=Jun 16 23:23 2017 
FILE=/.BAD/20468154

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
BAD/DUP FILE I=1219937  OWNER=root MODE=100600
SIZE=4096 MTIME=Jun 16 23:23 2017 
CLEAR? yes

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

282705 files, 2127437 used, 408434 free (66 frags, 51046 blocks, 0.0% fragmentation)

***** FILE SYSTEM MARKED DIRTY *****

***** FILE SYSTEM WAS MODIFIED *****

***** PLEASE RERUN FSCK *****
不良セクタを認識し、特別な処理をしたようだ。この後、また fsck をかけるように出る。
# fsck_ufs -y /dev/ada0s2e
** /dev/ada0s2e
** Last Mounted on /usr/local
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
282705 files, 2127437 used, 408434 free (66 frags, 51046 blocks, 0.0% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****
今度は正常に終了したようだ。

前回

badsect ではマウントできないファイルシステムは回避できない2017年05月19日 17時44分47秒

FreeBSD には badsect という不良セクタを回避するプログラムがある。不良セクタが出ていたので試そうとしたが、今回は無理なケースだった。これはファイルをあらかじめ作成して、以降の利用を防ぐので、ファイルシステムが機能しないと使えない。

fsck を何度かけても、特定の場所で失敗する。

$ fsck_yfs -y /dev/ada0s2e
** /dev/ada0s2e
** Last Mounted on /usr/local
** Phase 1 - Check Blocks and Sizes

CANNOT READ BLK: 20468128
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 20468153, 20468154,
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
215141 files, 2680121 used, 2396958 free (27470 frags, 296186 blocks, 0.5% fragmentation)

***** FILE SYSTEM STILL DIRTY *****

***** PLEASE RERUN FSCK *****
本来なら、
$ mkdir .BAD
$ badsect .BAD 20468153 20468154
なのだろう。

しかし、かなりのダメージがあるようで、

# mount -onoatime /dev/ada0s2e /mnt/ufs
mount: /dev/ada0s2e: R/W mount of /usr/local denied.
Filesystem is not clean - run fsck.: Operation not permitted
と失敗する。

ここから復帰するには、newfs は避けられない様に見える。

次回

FreeBSD で lockd を後から起動したら mount をやり直す2017年04月24日 21時04分27秒

NFS v3 では、ファイルのロックは NFS 自体の実装では提供されていないので、別途 lockd デーモンを起動する。もし、NFS を
$ sh /etc/rc.d/nfsd onestart
等のように、手動で NFS を起動した場合に、lockd の起動を忘れることがある。

lockd デーモンも同じように起動する。

$ sh /etc/rc.d/nfsd onestart
lockd と nfsd デーモンは独立しているので、片方だけ起動しても自動的には起動しない。

lockd デーモンを起動する前に、既に mount されたファイルシステムには、ファイルロックが有効にはならないようだ。一度、umount して、mount すると、ロックが有効になった。

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)

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

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 の方の引数が、若干変わる。

zpool で zfs プールの名前を変更2016年02月25日 13時43分43秒

zfs send で二つの zpool を統合した。広くした「bkup」プールに普段用の「zfs」から、ファイルシステムを移動した。実は ZFS のプールの名前が「zfs」だと、慣れていないと混乱しやすくなる。何はともあれ、私的利用には以前の利用形式の「zfs」プール名がいい。

zfs にはファイルシステムの名前を変更する zfs rename がある。zpool には rename コマンドは存在しないが、zpool import を用いて名前を変更することが出来る。

注意点としては、

  • 新旧のプール名は export しておく。
  • zfs でマウントポイントの変更を忘れないように。
  • マウントポイントを変える前に zfs unmount が必要。
等がある。

「bkup」プールを「zfs」プールに名前を変更して、/mnt/zfs にマウントポイントを替える。zpool import の第一引数は現在のプールの名前で、第二引数は新しいプールの名前になる。

# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
bkup  1.82T  1.59T   239G         -      -    87%  1.00x  ONLINE  -
zfs    698G   578G   120G         -      -    82%  1.00x  ONLINE  -
# zpool export zfs
# zpool export bkup
# zpool import bkup zfs
# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zfs   1.82T  1.59T   239G         -      -    87%  1.00x  ONLINE  -
# zfs set mountpoint=zfs zfs
cannot set property for 'zfs': 'mountpoint' must be an absolute path, 'none', or 'legacy'
# zfs set mountpoint=/mnt/zfs zfs
作業は FreeBSD 10.2-RELEASE で行ったが、zpool と zfs のコマンドはどこでも共通。

zfs send でファイルシステムを複製する2016年02月24日 12時40分33秒

zfs send と zfs receive は、旧来の dump と restore に相当するもの。zfs send でバックアップを取り、zfs receive で復元する。

以前はこのコマンドはスナップショットしか取れなかったが、FreeBSD 10.2-RELEASE の物は、ファイルシステムや、ボリュームも複製できるようになっている。「--head--」と呼ばれるスナップショットが作られて、それが送られる形だ。また、スナップショット用の zfs send と違い、ファイルシステムはマウントされていてはいけない。

# zfs send zfs/pict | zfs receive -n -v bkup/pict
warning: cannot send 'zfs/pict': target is busy; if a filesystem, it must not be
 mounted
cannot receive: failed to read from stream

写真がたまって手狭になった zfs プールの pict ファイルシステムを拡張した bkup プールに移動する。

# zfs send zfs/pict | zfs receive -v bkup/pict
receiving full stream of zfs/pict@--head-- into bkup/pict@--head--
received 256GB stream in 15303 seconds (17.1MB/sec)
# zfs list -t all
NAME                     USED  AVAIL  REFER  MOUNTPOINT
...
bkup/pict                253G   131G   253G  /mnt/bkup/pict
bkup/pict@--head--          0      -   253G  -
,,,
zfs/pict                 262G  98.7G   254G  /mnt/zfs/pict
zfs/pict@2015_11_14     8.71G      -   236G  -
見ての通り、「--head--」タグが残るのは受信側だけのようだ。また、この方法ではスナップショットが保存されていないのが分かる。

zpool を拡張し、新たな容量を確保2016年02月23日 13時30分04秒

zpool のデバイスを交換した。五年ぐらい前には zpool replace をして、新しいディスクの容量が大きければ、自動的に大きくなっていたのを覚えているが、最近の ZFS は動作が変わったようだ。FreeBSD 10.2-RELEASE を用いている。

zpool には autoexpand と言う属性がある。初期値は off になっている。これを on にすると、ディスクが交換された時に、新たな容量が利用可能になっていると、自動的に認識して容量が拡大される。mirror や raidz の時にはそれぞれの領域が拡張可能にならないと利用可能にならない。off の時は、zpool online -e にて拡張できる。

zpool list でどれだけ利用可能か調べられる。932GB 程広げられるようになった。

# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
bkup   931G   692G   239G      932G      -    74%  1.00x  ONLINE  -
$ zpool status
  pool: bkup
 state: ONLINE
status: ...
action: ...
  scan: resilvered 16 in 7h56m with 0 errors on Mon Feb 22 00:53:02 2016
config:

        NAME              STATE     READ WRITE CKSUM
        bkup              ONLINE       0     0     0
          raidz1-0         ONLINE       0     0     0
            gpt/zfs5       ONLINE       0     0     0
            gpt/zfs6       ONLINE       0     0     0
            gpt/zfs3       ONLINE       0     0     0
            gpt/zfs7       ONLINE       0     0     0
raidz 編成でどのデバイスに対して online を行えば分からなかったので、取り敢えず一番最初の物に。
# zpool online -e bkup gpt/zfs5
# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
bkup  1.82T   692G  1.14T         -      -    37%  1.00x  ONLINE  -
無事に拡張できたようだ。