ChienomiChienomirsyncでなくsend/receiveを使うことでBtrfsに戻す概要btrfsがrsyncで死んでしまうので、現在はLVM+XFSを使用しているが、いい加減容量は限界近いのでbtrfsに戻す。rsyncで詰んでしまう以上、rsyncではなく、send/receiveを用いたものとする。wikiによれば、rsyncを用いるよりも遥かに高速なのだという。/MirrorRootクライアント側スクリプト。/etc/ssh/sshd_config挙動btrfsのsnapshotやsend/receiveについて知識がなかったため、挙動をひとつひとつ確認することにした。snapshotはディレクトリに見える。そのディレクトリにはスナップショットの完全なファイルがあるように見える。常時アクセス可能な凍結された状態が存在するわけだ。スナップショットは元となるボリュームにネストされたサブボリュームになる。/fooにマウントされているサブボリュームのスナップショットは、/foo/snapshot1のようになるというわけだ。この外、例えば/barには置けない。この/foo/snapshot1はmvは可能だが、rmはできない。deleteでなければならない。このスナップショットをsendする時、-pオプションがなければそのsnapshotを構成する全体を送信する。あれば、指定されたサブボリューム(マウントされたディレクトリを指定)との差分を送信する。内容は標準出力に吐かれ、-fオプションで保存することもできるが、それはリダイレクトで保存しても良いようだ。receiveについても、およそ似たような挙動である。標準出力から読んで再編成するか、もしくは-fオプションでファイルから編成する。これは、sharのようなものではなく、編成されるのはスナップショットである。snapshot1というsnapshotをreceiveした場合、snapshot1というsnapshotが作られる。mvで名前が変わった状態で、-pオプション付きで送りつけたsnapshotがどうなるのかは、まだ試していない。snapshotにロールバックする場合は、マウントポイントの付け替えと、サブボリュームのデリートでよさそうだ。set-defaultが必要か?多くのスナップショットを維持することでディスク容量やI/Oにどのように影響するのかはわからない。英語文書を読めばよいのかもしれないが、なかなか大変そうなので、そこには当面手を付ける予定はない。思わぬつまづきrootユーザーでRSA鍵でsshログインできないという問題に遭遇した。-dで起動した場合は通る。デバッグモードなら通るため、メッセージの確認もできない。