2020年 02月 27日
SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット
久しぶりに SUSE 11 の仮想マシンを起動したら、見事にコケました、仕方がないので、 fsck して起動しましたが、あまりいいものじゃありません。SUSE Linux Enterprise 12 から採用され、以降 SUSE Linux 15(SLE/openSUSE15) で openSUSE Leap で使われている BtrFS は、やれ「修復のため起動時の fsck の必要がない」とか、fsck しないので起動が速いとか、起動中にファイルシステムのチェックができるとか、いいことばかり書かれています。実際、この記事を書く時にたどり着いた情報は「BtrFS にクソハマった話」ばかりなのですが、それほど情報が少ないのはやはり安心して使えるファイルシステムだからでしょう。現実には、論理障害よりも、物理障害もあるわけですから、
「困った!」
時のために、BtrFS の、修復だとかチェック、メンテナンス、スナップショットの設定の方法について、ちゃんと勉強しておくことにします。- 参考にしたドキュメント -
SDB:BTRFS
btrfs scrub start [mount_point]パーティションの論理障害を修復します。
opesuse151:~ # btrfs scrub start /scrub started on /, fsid 8466aee4-2738-4b0a-924a-79edad4b4676 (pid=23058)opesuse151:~ #
brtfs scrub status [mount_point]scrub した結果を確認します。
opesuse151:~ # btrfs scrub status /scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50total bytes scrubbed: 7.54GiB with 0 errorsopesuse151:~ #
-dR オプションを付けると詳細な情報が分かります。
opesuse151:~ # btrfs scrub status -dR /scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676scrub device /dev/vda2 (id 1) historyscrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50data_extents_scrubbed: 247304tree_extents_scrubbed: 31902data_bytes_scrubbed: 7577907200tree_bytes_scrubbed: 522682368read_errors: 0csum_errors: 0verify_errors: 0no_csum: 5030csum_discards: 0super_errors: 0malloc_errors: 0uncorrectable_errors: 0unverified_errors: 0corrected_errors: 0last_physical: 11178868736opesuse151:~ #
btrfs check [/dev/partition]ファイルシステムのパーティションチェックです。※ --force を付けるとマウント中のファイルシステムをチェックできる。
opesuse151:~ # btrfs check --force /dev/vda2Opening filesystem to check...WARNING: filesystem mounted, continuing because of --forceChecking filesystem on /dev/vda2UUID: 8466aee4-2738-4b0a-924a-79edad4b4676[1/7] checking root items[2/7] checking extents[3/7] checking free space cache[4/7] checking fs roots[5/7] checking only csums items (without verifying data)[6/7] checking root refs[7/7] checking quota groups skipped (not enabled on this FS)found 7839363072 bytes used, no error foundtotal csum bytes: 7380260total tree bytes: 261373952total fs tree bytes: 238518272total extent tree bytes: 13942784btree space waste bytes: 41699539file data blocks allocated: 7779311616referenced 7561506816opesuse151:~ #
btrfs filesystem df [mount_point]従来の df コマンドの代わりになるものです。
opesuse151:~ # btrfs filesystem df /Data, single: total=8.01GiB, used=7.06GiBSystem, DUP: total=32.00MiB, used=16.00KiBMetadata, DUP: total=1.12GiB, used=249.25MiBGlobalReserve, single: total=21.73MiB, used=0.00Bopesuse151:~ #
btrfs filesystem usage [mount_point]
opesuse151:~ # btrfs filesystem usage /Overall:Device size: 14.00GiBDevice allocated: 10.32GiBDevice unallocated: 3.68GiBDevice missing: 0.00BUsed: 7.54GiBFree (estimated): 4.63GiB (min: 2.79GiB)Data ratio: 1.00Metadata ratio: 2.00Global reserve: 21.73MiB (used: 0.00B)Data,single: Size:8.01GiB, Used:7.06GiB/dev/vda2 8.01GiBMetadata,DUP: Size:1.12GiB, Used:249.25MiB/dev/vda2 2.25GiBSystem,DUP: Size:32.00MiB, Used:16.00KiB/dev/vda2 64.00MiBUnallocated:/dev/vda2 3.68GiBopesuse151:~ #
sysconfig の File systems の中に、自動メンテナンスの間隔を設定します。"BTRFS_BALANCE_PERIOD" のキーに設定されます。デフォルトは weekly となっています。
SDB:Disable btrfsmaintenance
weekly から none にすると、無効となります。
snapper は初期設定では無効です。snapper コマンドでスナップショットを初期化します。snapper -c create [YourSnapSotName] create-config [PathToYouNeedSpapShot]ここではルートパーティション全体を取っていますが、例えば DB ファイルがあるところとか、 /srv/www/htdocs などを指定します。設定ファイルは /etc/snapper/configs/ の下に作られます。
opesuse151:~ # snapper -c mysnapconfig create-config /opesuse151:~ #opesuse151:~ # ls /etc/snapper/configs -ltotal 4-rw-r----- 1 root root 1169 Feb 27 10:37 mysnapconfigopesuse151:~ #opesuse151:~ # cat /etc/snapper/configs/mysnapconfig# subvolume to snapshotSUBVOLUME="/"# filesystem typeFSTYPE="btrfs"# btrfs qgroup for space aware cleanup algorithmsQGROUP=""# fraction of the filesystems space the snapshots may useSPACE_LIMIT="0.5"# fraction of the filesystems space that should be freeFREE_LIMIT="0.2"# users and groups allowed to work with configALLOW_USERS=""ALLOW_GROUPS=""# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots# directorySYNC_ACL="no"# start comparing pre- and post-snapshot in background after creating# post-snapshotBACKGROUND_COMPARISON="yes"# run daily number cleanupNUMBER_CLEANUP="yes"# limit for number cleanupNUMBER_MIN_AGE="1800"NUMBER_LIMIT="50"NUMBER_LIMIT_IMPORTANT="10"# create hourly snapshotsTIMELINE_CREATE="yes"# cleanup hourly snapshots after some timeTIMELINE_CLEANUP="yes"# limits for timeline cleanupTIMELINE_MIN_AGE="1800"TIMELINE_LIMIT_HOURLY="10"TIMELINE_LIMIT_DAILY="10"TIMELINE_LIMIT_WEEKLY="0"TIMELINE_LIMIT_MONTHLY="10"TIMELINE_LIMIT_YEARLY="10"# cleanup empty pre-post-pairsEMPTY_PRE_POST_CLEANUP="yes"# limits for empty pre-post-pair cleanupEMPTY_PRE_POST_MIN_AGE="1800"
詳細はこちらをご参考下さい。
4 SnapperによるスナップショットとロールバックSLES12 の Snapper のチューニング
snapper を起動したら、YaST2 snapper で、スナップショットの設定をします。opesuse151:~ # yast2 & 定義したパーティションルートに .snapshot ディレクトリが創られます。ここは snapshot の保管場所です。
opesuse151:~ # ls /.snapshots/1/snapshot/.snapshots boot etc lib mnt proc run selinux sys usrbin dev home lib64 opt root sbin srv tmp varopesuse151:~ #
実際のスナップショットの取り方、ロールバックの方法はこちらの過去記事をご参考にしてください。
SLES12が採用した btrfs, snapper を使った Snap Shot
なるほど、SUSE Linux 12, 15 でルートパーティションは標準の BtrFS は COW (Copy On Write) なので、ファイルの論理障害には強いんだ、という事です。しかし物理障害には無力な事には変わりません。やっぱり必要なのはバックアップです。一通りやってみて、Windows の起動直後の chkdisk や EXT3 の場合の fsck の待ち時間を考えると実に楽になったなと実感しています。
