相方が携帯紛失

うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。

# xm pause debian
# lvcreate -s -n snapdebian -L 200G /dev/ms09/debian
  Logical volume "snapdebian" created
# xm unpause debian

としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。

# e2fsck -yfv /dev/ms09/snapdebian
e2fsck 1.41.12 (17-May-2010)
/dev/ms09/snapdebian: recovering journal
Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20)
Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED *****

  715619 inodes used (2.13%)
     738 non-contiguous files (0.1%)
     182 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 706955/133
23572155 blocks used (17.56%)
       0 bad blocks
       6 large files

  677160 regular files
   29784 directories
     126 character device files
      40 block device files
       2 fifos
      16 links
    8469 symbolic links (8324 fast symbolic links)
      29 sockets
--------
  715626 files

マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。

[  647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504
[  647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503
[  647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502
[  647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501
[  647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500
[  647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted
[  647.099710] EXT4-fs (dm-18): recovery complete
[  647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode
[ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds.
[ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.113201] umount        D 0000000000000000     0  4061   2294 0x00000000
[ 1080.113331]  ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8
[ 1080.113544]  0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8
[ 1080.117004]  0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8
[ 1080.117004] Call Trace:
[ 1080.117004]  [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa
[ 1080.117004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe
[ 1080.117004]  [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe
[ 1080.117004]  [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70
[ 1080.117004]  [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77
[ 1080.117004]  [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23
[ 1080.117004]  [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a
[ 1080.117004]  [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70
[ 1080.117004]  [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa
[ 1080.117004]  [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 1080.117004]  [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a
[ 1080.117004]  [<ffffffff810f226d>] ? deactivate_super+0x60/0x77
[ 1080.117004]  [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b
[ 1080.117004]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b

場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。

この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。

その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。

# lvremove -f /dev/ms09/snapdebian
  Unable to deactivate open ms09-debian-real (254:5)
  Failed to resume debian.

これに関してはバグレポートが見つかった。
とりあえず4ヶ月経過しても治っていないらしい。

んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。

あー、設定するのがめんどくさい。