上面这些情况，要是你遇到了，应该如何面对和处理？有些人对自我感觉，自我认同是没有太多认知的，甚至于某些家庭里，强势的养育者会强行灌输自己个人的认知和价值观。即使自己有点自我意识，很多情况下他们为了自己的权威性，会强行掐灭与自己不同的声音，和各种自我觉醒、反抗的念头，久而久之，要么就是习得性无助，要么就是心里压抑了更多深层次的愤怒，等待有机会的时候再爆发。

首先，当别人抛出这些不怎么友好的评价、和观点的时候，他们在潜意识中是把自己无法处理的矛盾、或者观点抛给（转移、投射给）了你（也许这样做，能让他们自己感觉到好受一些），在处于第三方视角，偷偷看你怎么处理和面对，因为他们自己也是不知道如何和自己内心那种矛盾相处和处理。当你自己的内心状态从平静，突然转到矛盾的状态的时候，你被对方各种花里胡哨语言暗示所击溃，以为自己真的出了问题，其实是你接收到了对方投射过来的矛盾。

当父母对自己子女说，“在外面要胆子大一点，挺起胸脯，不要缩缩闪闪”，其实是暗示你现在还不够自信，胆子小，社会地位低。当你接收到这样的矛盾时，大多数人都会陷入到他们的理论框架中：要么认同，要么反对。认同他们的理论，想办法让自己更自信一点，变得更大胆一些，可是总有某些时候，内心会突然升起很多恐惧，为什么自己还不够自信；反对他们的理论，他们说什么，都反着来，都反对，都不听，你会逐渐发现，不管做什么其实受到了他人的牵制，你的脆弱的神经都在被别人所影响。其实不管是认同还是反对对方的观点，都受到了对方的牵制，失去了自由，陷入对方的矛盾陷阱之中。

那么，当我们发现自己不小心陷入了对方的矛盾陷阱中，应该如何自救呢？之前的文章说过，如果想跳出矛盾的循环，就必须至少站在中立的立场上，然后站在更高的角度上俯视当前的矛盾，找出这个矛盾的超集。把自己的注意力一直集中在中立的立场上，中立既是和正向立场相关，又是和负向立场相关，甚至于和正负立场不相关的，也可以称为中立。只要你不站在和对方对立的立场和对立面上，对方的攻击、抵抗的行为则会消减很多，进而冷静下来，听你接下来的表达。

比如，我妈一直抓着我留胡子的事情不放，我当时听到了心里有点生气，但我意识到之后，开始寻找相关事情的中立面，既不是去反驳我妈说的东西，也不去赞同她说的观点。视频里，我开始不把自己的胡子露出来（不站在对方对立面），继续聊其它事情（中立的事情），聊着聊着，聊天的气氛慢慢轻松了很多，我也差不多消气了。后面情绪冷静下来，才意识到她这样说只是他们老一辈的观念而已（跳出了事件本身）。

是的，矛盾的真正解决，大部分都不在矛盾本身，在于矛盾力量的平衡，所以我们始终都要站在中立的角度上，直到称为主要矛盾，我们再也无法中立。矛盾的真正解决始终都在它们的上一层次，超集里。

有句话说得好，当你被别人诬陷的时候，不要尝试去自证，就是这样的原理。自证就是掉进了他人说话的框架里，搅和进他人的矛盾关系中，参与进了他们的因果。

后面越来越发现，遇到讨厌的场景没有变少，不管如何地防御和保护自己，只要心中有那种讨厌的情绪和愤怒，就会吸引和遇到相似的人和事，就像有共鸣一样：这种微妙的情绪和心理，不管隐藏有多深，总会莫名其妙地吸引同一类人反应。

我的眼睛，总是会看向别人，把别人的身上的点放大来看，认为是对方的错，是对方伤害了自己，做了不公平的事情，对方应该为此负责。估计这时别人也是这样想，是我的错，我导致了对方的不开心，不舒服的情绪，我应该负责。于是，这样的错位纠缠—–争斗和矛盾就开始了。

那怎样从这样的斗争矛盾陷阱中跳出来呢？一个巴掌拍不响，只要有一只手停下来，其中的一方可以觉醒和认知这件事情，斗争和矛盾才会停止和结束。最近我意识到了，“讨厌别人的那部分，其实源于讨厌自己的那部分特质”。

怎么说呢，人最常见的无意识心理行为，就是心理投射，把自己认知、显性意识、潜意识投射到周围的环境和人身上，而自己却不自知。假如他认为世界是危险的，那么他看到的世界和社会，人与人之间的关系，都将是“危险的”。他讨厌某样东西的时候，潜意识会自动搜寻和注意这样东西的相关踪迹，并比一般人的敏感度更高，一旦发现，潜意识会自动拉起警报，并自动触发相关的防御机制，自动产生相关的行为。

当我意识到，我讨厌别人身上“那种霸凌他人”的特质的时候，其实就是讨厌自己身上拥有这样的特质，但是本来自己确实拥有这样的特质，但是被自己隐藏起来了，压抑到自己看不见的地方，然后以为自己没有，而别人有，才升起这种愤怒。

我小时候的脾气是比较火爆的，一有不满就大声呵斥妹妹，甚至于动手。后面长大了，渐渐地认为性格温和的人真好，脾气火爆的人很差，就做起了好好先生，把自己另外一面隐藏起来。直到有一次，对象愤怒和我控诉，说我经常对他冷暴力，拒绝和他沟通，不给对方发泄不满的机会，我才发现自己原来也有这样暴力的一面。

这一切源于什么呢？源于分别心。之前的文章说过，世间的真相是“好”和“坏”是各占一半的，一个正常的人，必定拥有一半美好的品格和一半邪恶的品格。但是我们学到最多的就是这种“为善去恶”这样的二元对立的观点，将一个完整的人的品格人为地分裂成“好的”和“坏的”，学会去压抑和消灭自己“坏”的部分。但是“坏”的部分无法被消灭，而且永远存在，只是被你隐藏到看不到的地方，它会时不时涌现出来，和你“好”的部分进行对抗和冲突，于是，你会很自然把自己内心这份冲突投射到周围的事物和人身上。压抑“坏”的力量只会导致自己丧失“坏”的生命力，黑暗的生命力，就像那些品格好、遵守规矩的孩子和那些调皮捣蛋的孩子对比，总像缺少了某种生命力。

关键在于什么呢？和解和平衡，允许自己“坏”的方面的存在，承认这是正常的，合理的。让自己不过于的“好”也不过于的“坏”，关键在于那个平衡和限度。

下次，再看到自己讨厌别人什么的时候，觉察自己的绝佳时刻就到了，借助这件“讨厌”的事情，来发现自己内心的失衡：讨厌别人什么样，必定是讨厌自己成为这样。觉察到这种失衡，我们可以继续好奇地探究，为什么自己讨厌这样的东西，其背后必定也隐藏着一个失衡念头、紧抓不住的信念。理解这种信念，并与它和解，才不会继续碰壁。

—————————————-GPT总结——————————————

文章核心要点总结

1. 最初的防御机制
   因童年被欺负或经历不公平，对“没有边界感”“咄咄逼人”“贬低他人”等特质极度抵触，形成心理防御，以此保护自己。
2. 防御失效的困境
   尽管不断回避，却总是反复遇到类似的人和事，意识到：内心的愤怒与讨厌情绪本身，会吸引和共鸣相似的外在情境。
3. 从外归因到内觉察
   原来总是放大别人的“错”，认为是对方伤害了自己；但矛盾的本质是“一个巴掌拍不响”，双方都在互相投射责任。
4. 关键觉醒：讨厌别人，其实是讨厌自己
   通过“心理投射”机制，我们将自己压抑的特质（如攻击性、控制欲）投射到他人身上，从而产生强烈反感。
   讨厌的不是别人，而是自己不敢承认的那部分“阴影”。
5. 个人觉察实例
   曾经脾气火爆，长大后压抑情绪，追求“好好先生”形象，却在亲密关系中表现出冷暴力——发现“暴力”并未消失，只是换了一种形式存在。
6. 问题的根源：分别心与压抑
   社会教育让我们追求“为善去恶”，将人性割裂为“好”与“坏”，导致对“坏”特质的过度压抑。
   但“坏”的部分无法被消灭，只会潜入潜意识，伺机反扑。
7. 压抑的代价：生命力的丧失
   过度压抑“坏”的一面，会让人失去真实的生命力，变得苍白、僵化，甚至以更隐蔽的方式伤害他人。
8. 解决之道：和解与平衡
   真正的成长不是消灭阴影，而是承认它存在的合理性，允许自己有愤怒、自私、攻击性，但不被其控制。
   在“好”与“坏”之间找到动态平衡，才是完整的人格。
9. 觉察的契机：每一次“讨厌”都是镜子
   当你再次对某人某事升起强烈反感时，正是向内探索的最佳时机——问问自己：
   “我为什么这么敏感？”“我是否也曾如此？”“我害怕成为这样的人吗？”
10. 最终目标：成为完整的人
    接纳自己的全部，包括光明与黑暗，才能停止对外界的投射与斗争，实现内在的自由与真正的善良——
    那种允许不完美，却依然选择爱的善良。

使用 tmux

初始化一个新的 tmux 会话： 如果你还没有在一个 tmux 会话中，首先你需要创建一个新的会话。


```bash
tmux new -s mysession
```

使用 reptyr 工具： 要将一个已经运行的进程转移到 tmux 会话中，可以使用 reptyr 工具。首先你需要安装 reptyr（具体安装命令视你的操作系统而定）。然后，在 tmux 会话中执行如下命令来“劫持”某个进程：


```bash
reptyr <pid>
```

其中 `<pid>` 是你想转移的那个进程的进程ID。

使用 screen

虽然 screen 没有直接支持类似 reptyr 的功能，但你可以利用一个叫做 screen 的特性，称为“多窗口”模式，结合一些技巧来实现这一点。

创建一个新的 screen 会话：


```bash
screen -S mysession
```

准备进行进程迁移： 首先，找到你想转移的进程的 PID。然后，暂停该进程（如果你有权限的话），例如通过发送 SIGSTOP 信号：


```bash
kill -STOP <pid>
```

使用 gdb 来重新设置进程的控制终端： 这一步比较复杂，而且可能不总是有效，取决于系统和进程类型。基本思路是使用 gdb 附加到这个进程上，并调用 signal(SIGCONT) 来恢复它，同时改变它的控制终端到 screen 会话中。这通常涉及复杂的 gdb 命令操作，并且超出了简单的教程范围。

恢复进程： 如果你成功地改变了进程的控制终端，你可以在 screen 会话中继续运行该进程：


```bash
kill -CONT <pid>
```

请注意，上述方法可能会因系统配置、权限以及特定进程的行为而有所不同。对于 screen 方法尤其如此，它可能并不适用于所有情况。使用 reptyr 是相对更简单也更可靠的选择，尤其是当你想要将任务转移到 tmux 或者新的 screen 会话中时。确保你在尝试这些操作前了解其风险，并备份重要数据。

代码模式

screen 也能用 reptyr 吗

是的，reptyr 也可以在 screen 会话中使用，以将已经运行的任务附加到 screen 会话里。尽管 screen 自身没有直接提供类似的功能，但通过 reptyr 工具，你可以实现在 screen 会话中接管其他终端上正在运行的程序。

这里是如何操作的基本步骤：

启动一个 screen 会话： 如果你还没有在一个 screen 会话中，请先启动一个新的会话。


```bash
screen -S mysession
```

找到你想转移的进程的 PID： 使用 ps, top, 或者其他任何工具来找到你想转移的那个进程的 PID。

暂停目标进程（如果需要）： 在某些情况下，你可能需要先暂停目标进程，以便能够成功地使用 reptyr 进行接管。


```bash
kill -STOP <pid>
```

其中 `<pid>` 是你的目标进程的 PID。

使用 reptyr 接管进程： 现在，在你的 screen 会话中运行 reptyr 并带上目标进程的 PID 来接管它。


```bash
reptyr <pid>
```

恢复进程（如果之前被暂停）： 如果你在第3步暂停了该进程，现在可以通过发送 SIGCONT 信号来恢复它。


```bash
kill -CONT <pid>
```

需要注意的是，虽然这种方法通常有效，但它可能会因为系统配置、权限设置以及特定进程的行为而有所不同。此外，进行这些操作时应该小心，确保你了解所有相关风险，并考虑备份重要数据以防万一。在大多数情况下，reptyr 提供了一个相对简单且强大的方法来将任务从一个终端转移到另一个，包括 tmux 和 screen 会话。

构建静态Python3的方法

前提条件

建议在 Alpine Linux 的 Docker 中编译

步骤说明

1. 确定静态编译模块

首先确定要静态编译进Python的模块，比如需要将 asyncio 模块静态编译到 python3，而 asyncio 会依赖其它的底层模块（_socket，math，select，array，_posixsubprocess，_contextvars 等），详细的官方库编译项可以在 Modules/Setup 中查找，需要一次次尝试查漏补缺。

2. 恢复源码目录初始状态

make distclean

3. 编写静态编译模块配置文件

将需要静态编译的模块信息写到文件 Modules/Setup.local 中：

vi Modules/Setup.local

内容如下：

*static*
_asyncio _asynciomodule.c
_socket socketmodule.c
math mathmodule.c _math.c -DPy_BUILD_CORE_MODULE
select selectmodule.c
array arraymodule.c
_posixsubprocess _posixsubprocess.c
_contextvars _contextvarsmodule.c
_struct _struct.c
binascii binascii.c

4. 执行 configure 配置

./configure LDFLAGS="-static" --disable-shared

检查环境中是否还缺少编译依赖。

5. 检查 Modules/Setup.local 文件

再次检查 Modules/Setup.local 文件，确保执行 configure 后没有被覆盖或者置空：

• 如果被修改覆盖了，需要重新写入 Modules/Setup.local，再执行第四步 ./configure LDFLAGS="-static" --disable-shared。
• 如果还是被覆盖了，检查 configure 过程中的报错。
• 还是不行的，删除当前源码，重新解压出原始源码，再次尝试。

6. 执行编译

根据实际情况进行多线程编译（-j 后面接线程数）：

make -j10 LDFLAGS="-static" LINKFORSHARED=" "

• LDFLAGS="-static" 代表是将静态编译的参数传进编译器
• LINKFORSHARED=" " 是置空 LINKFORSHARED 变量，避免编译出共享库 so

7. 测试运行

当前目录直接测试运行是否正常，是否报缺失模块：

ldd ./python  # 查看执行文件是否静态
./python xxxx.py

8. 打包 Python3 程序

程序运行正常就可以打包 python3 程序了（bin 文件 + lib PY 类型的依赖库）：

pwd
/root/0616/Python-3.9.23

将程序临时安装在目录下的 1 路径：

make install LDFLAGS="-static" LINKFORSHARED=" " DESTDIR=/root/0616/Python-3.9.23/1

将 /root/0616/Python-3.9.23/2 目录下的文件打包到目标环境上的机器即可运行：

ls /root/0616/Python-3.9.23/2/usr/local/lib/
libpython3.9.a  pkgconfig       python3.9

执行以下命令复制文件到目标环境：

rsync -avP /root/0616/Python-3.9.23/2/usr/local/ root@new:/usr/local/
ln -sv /usr/local/bin/python3 /usr/bin/python3-static

更简单的：只用复制静态 python 文件和 usr/local/lib/python3.9 到目标环境中即可。

官方文档（Building Python Statically）： https://wiki.python.org/moin/BuildStatically

1. 模块选择与确认

首先确定要静态编译进Python的模块，例如需要将asyncio模块静态编译到python3。可以通过查看Modules/Setup文件来了解详细的官方库编译项。

2. 清理源码目录

执行以下命令将源码目录恢复到初始状态：

make distclean

3. 配置 Modules/Setup.local

将需要静态编译的模块信息写入Modules/Setup.local文件，例如：

*static*
_asyncio _asynciomodule.c
_socket socketmodule.c
math mathmodule.c _math.c -DPy_BUILD_CORE_MODULE
select selectmodule.c
array arraymodule.c
_posixsubprocess _posixsubprocess.c
_contextvars _contextvarsmodule.c
_struct _struct.c
binascii binascii.c

4. 执行 configure

运行以下命令进行配置，确保环境中没有缺少编译依赖：

./configure LDFLAGS="-static" --disable-shared

如果Modules/Setup.local被修改或覆盖，请重新写入该文件并再次执行此步骤。若仍存在问题，可检查configure过程中的报错信息。

5. 编译 Python3 程序

根据实际情况进行多线程编译：

make -j10 LDFLAGS="-static" LINKFORSHARED=" "

6. 测试运行与静态链接验证

在当前目录直接测试运行程序，确保没有缺失模块：

ldd ./python   # 查看执行文件是否为静态编译
./python xxxx.py

7. 打包 Python3 程序

将编译好的Python3程序打包到目标环境中：

pwd
/root/0616/Python-3.9.23

make install LDFLAGS="-static" LINKFORSHARED=" " DESTDIR=/root/0616/Python-3.9.23/1

8. 部署与复制

将打包好的文件部署到目标环境：

ls /root/0616/Python-3.9.23/2/usr/local/lib/
libpython3.9.a  pkgconfig       python3.9

rsync -avP /root/0616/Python-3.9.23/2/usr/local/ root@new:/usr/local/
ln -sv /usr/local/bin/python3-static /usr/bin/python3

简化部署方案

更简单的做法是只复制静态编译后的Python文件和相关依赖库到目标环境：

cp ./python3.9.static /target/path/
cp /root/0616/Python-3.9.23/2/usr/local/lib/python3.9 /target/path/

这样，程序就可以在几乎任何发行版上零依赖运行。

记得 docker run -it redis8-6383 chmod 777 -Rv /redis

Introduction

BTRFS is an advanced filesystem mostly contributed by Sun/Oracle whose origins take place in 2007. A good summary is given in [1]. BTRFS aims to provide a modern answer for making storage more flexible and efficient. According to its main contributor, Chris Mason, the goal was “to let Linux scale for the storage that will be available. Scaling is not just about addressing the storage but also means being able to administer and to manage it with a clean interface that lets people see what’s being used and makes it more reliable.” (Ref. http://en.wikipedia.org/wiki/Btrfs).

Btrfs, often compared to ZFS, is offering some interesting features like:

• Using very few fixed location metadata, thus allowing an existing ext2/ext3 filesystem to be “upgraded” in-place to BTRFS.
• Operations are transactional
• Online volume defragmentation (online filesystem check is on the radar but is not yet implemented).
• Built-in storage pool capabilities (no need for LVM)
• Built-in RAID capabilities (both for the data and filesystem metadata). RAID-5/6 is planned for 3.5 kernels
• Capabilities to grow/shrink the volume
• Subvolumes and snapshots (extremely powerful, you can “rollback” to a previous filesystem state as if nothing had happened).
• Copy-On-Write
• Usage of B-Trees to store the internal filesystem structures (B-Trees are known to have a logarithmic growth in depth, thus making them more efficient when scanning)

Requirements

A recent Linux kernel (BTRFS metadata format evolves from time to time and mounting using a recent Linux kernel can make the BTRFS volume unreadable with an older kernel revision, e.g. Linux 2.6.31 vs Linux 2.6.30). You must also use sys-fs/btrfs-progs (0.19 or better use -9999 which points to the git repository).

Playing with BTRFS storage pool capabilities

Whereas it would possible to use btrfs just as you are used to under a non-LVM system, it shines in using its built-in storage pool capabilities. Tired of playing with LVM ?  Good news: you do not need it anymore with btrfs.

Setting up a storage pool

BTRFS terminology is a bit confusing. If you already have used another ‘advanced’ filesystem like ZFS or some mechanism like LVM, it’s good to know that there are many correlations. In the BTRFS world, the word volume corresponds to a storage pool (ZFS) or a volume group (LVM). Ref. http://www.rkeene.org/projects/info/wiki.cgi/165

The test bench uses disk images through loopback devices. Of course, in a real world case, you will use local drives or units though a SAN. To start with, 5 devices of 1 GiB are allocated:

# dd if=/dev/zero of=/tmp/btrfs-vol0.img bs=1G count=1
# dd if=/dev/zero of=/tmp/btrfs-vol1.img bs=1G count=1
# dd if=/dev/zero of=/tmp/btrfs-vol2.img bs=1G count=1
# dd if=/dev/zero of=/tmp/btrfs-vol3.img bs=1G count=1
# dd if=/dev/zero of=/tmp/btrfs-vol4.img bs=1G count=1

Then attached:

# losetup /dev/loop0 /tmp/btrfs-vol0.img
# losetup /dev/loop1 /tmp/btrfs-vol1.img
# losetup /dev/loop2 /tmp/btrfs-vol2.img
# losetup /dev/loop3 /tmp/btrfs-vol3.img
# losetup /dev/loop4 /tmp/btrfs-vol4.img

Creating the initial volume (pool)

BTRFS uses different strategies to store data and for the filesystem metadata (ref. https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices).

By default the behavior is:

• metadata is replicated on all of the devices. If a single device is used the metadata is duplicated inside this single device (useful in case of corruption or bad sector, there is a higher chance that one of the two copies is clean). To tell btrfs to maintain a single copy of the metadata, just use single. Remember: dead metadata = dead volume with no chance of recovery.
• data is spread amongst all of the devices (this means no redundancy; any data block left on a defective device will be inaccessible)

To create a BTRFS volume made of multiple devices with default options, use:

# mkfs.btrfs /dev/loop0 /dev/loop1 /dev/loop2 

To create a BTRFS volume made of a single device with a single copy of the metadata (dangerous!), use:

# mkfs.btrfs -m single /dev/loop0

To create a BTRFS volume made of multiple devices with metadata spread amongst all of the devices, use:

# mkfs.btrfs -m raid0 /dev/loop0 /dev/loop1 /dev/loop2 

To create a BTRFS volume made of multiple devices, with metadata spread amongst all of the devices and data mirrored on all of the devices (you probably don’t want this in a real setup), use:

# mkfs.btrfs -m raid0 -d raid1 /dev/loop0 /dev/loop1 /dev/loop2 

To create a fully redundant BTRFS volume (data and metadata mirrored amongst all of the devices), use:

# mkfs.btrfs -d raid1 /dev/loop0 /dev/loop1 /dev/loop2 

Checking the initial volume

To verify the devices of which BTRFS volume is composed, just use btrfs-show device (old style) or btrfs filesystem show device (new style). You need to specify one of the devices (the metadata has been designed to keep a track of the what device is linked what other device). If the initial volume was set up like this:

# mkfs.btrfs /dev/loop0 /dev/loop1 /dev/loop2

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/loop1 id 2
adding device /dev/loop2 id 3
fs created label (null) on /dev/loop0
        nodesize 4096 leafsize 4096 sectorsize 4096 size 3.00GB
Btrfs Btrfs v0.19

It can be checked with one of these commands (They are equivalent):

# btrfs filesystem show /dev/loop0
# btrfs filesystem show /dev/loop1
# btrfs filesystem show /dev/loop2

The result is the same for all commands:

Label: none  uuid: 0a774d9c-b250-420e-9484-b8f982818c09
        Total devices 3 FS bytes used 28.00KB
        devid    3 size 1.00GB used 263.94MB path /dev/loop2
        devid    1 size 1.00GB used 275.94MB path /dev/loop0
        devid    2 size 1.00GB used 110.38MB path /dev/loop1

To show all of the volumes that are present:

# btrfs filesystem show
Label: none  uuid: 0a774d9c-b250-420e-9484-b8f982818c09
        Total devices 3 FS bytes used 28.00KB
        devid    3 size 1.00GB used 263.94MB path /dev/loop2
        devid    1 size 1.00GB used 275.94MB path /dev/loop0
        devid    2 size 1.00GB used 110.38MB path /dev/loop1

Label: none  uuid: 1701af39-8ea3-4463-8a77-ec75c59e716a
        Total devices 1 FS bytes used 944.40GB
        devid    1 size 1.42TB used 1.04TB path /dev/sda2

Label: none  uuid: 01178c43-7392-425e-8acf-3ed16ab48813
        Total devices 1 FS bytes used 180.14GB
        devid    1 size 406.02GB used 338.54GB path /dev/sda4

Mounting the initial volume

BTRFS volumes can be mounted like any other filesystem. The cool stuff at the top on the sundae is that the design of the BTRFS metadata makes it possible to use any of the volume devices. The following commands are equivalent:

# mount /dev/loop0 /mnt
# mount /dev/loop1 /mnt
# mount /dev/loop2 /mnt

For every physical device used for mounting the BTRFS volume df -h reports the same (in all cases 3 GiB of “free” space is reported):

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop1      3.0G   56K  1.8G   1% /mnt

The following command prints very useful information (like how the BTRFS volume has been created):

# btrfs filesystem df /mnt      
Data, RAID0: total=409.50MB, used=0.00
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=204.75MB, used=28.00KB
Metadata: total=8.00MB, used=0.00

By the way, as you can see, for the btrfs command the mount point should be specified, not one of the physical devices.

Shrinking the volume

A common practice in system administration is to leave some head space, instead of using the whole capacity of a storage pool (just in case). With btrfs one can easily shrink volumes. Let’s shrink the volume a bit (about 25%):

# btrfs filesystem resize -500m /mnt
# dh -h
/dev/loop1      2.6G   56K  1.8G   1% /mnt

And yes, it is an on-line resize, there is no need to umount/shrink/mount. So no downtimes!  However, a BTRFS volume requires a minimal size… if the shrink is too aggressive the volume won’t be resized:

# btrfs filesystem resize -1g /mnt  
Resize '/mnt' of '-1g'
ERROR: unable to resize '/mnt'

Growing the volume

This is the opposite operation, you can make a BTRFS grow to reach a particular size (e.g. 150 more megabytes):

# btrfs filesystem resize +150m /mnt
Resize '/mnt' of '+150m'
# dh -h
/dev/loop1      2.7G   56K  1.8G   1% /mnt

You can also take an “all you can eat” approach via the max option, meaning all of the possible space will be used for the volume:

# btrfs filesystem resize max /mnt
Resize '/mnt' of 'max'
# dh -h
/dev/loop1      3.0G   56K  1.8G   1% /mnt

Adding a new device to the BTRFS volume

To add a new device to the volume:

# btrfs device add /dev/loop4 /mnt 
oxygen ~ # btrfs filesystem show /dev/loop4 
Label: none  uuid: 0a774d9c-b250-420e-9484-b8f982818c09
        Total devices 4 FS bytes used 28.00KB
        devid    3 size 1.00GB used 263.94MB path /dev/loop2
        devid    4 size 1.00GB used 0.00 path /dev/loop4
        devid    1 size 1.00GB used 275.94MB path /dev/loop0
        devid    2 size 1.00GB used 110.38MB path /dev/loop1 

Again, no need to umount the volume first as adding a device is an on-line operation (the device has no space used yet hence the ‘0.00’). The operation is not finished as we must tell btrfs to prepare the new device (i.e. rebalance/mirror the metadata and the data between all devices):

# btrfs filesystem balance /mnt
# btrfs filesystem show /dev/loop4
Label: none  uuid: 0a774d9c-b250-420e-9484-b8f982818c09
        Total devices 4 FS bytes used 28.00KB
        devid    3 size 1.00GB used 110.38MB path /dev/loop2
        devid    4 size 1.00GB used 366.38MB path /dev/loop4
        devid    1 size 1.00GB used 378.38MB path /dev/loop0
        devid    2 size 1.00GB used 110.38MB path /dev/loop1

Removing a device from the BTRFS volume

# btrfs device delete /dev/loop2 /mnt
# btrfs filesystem show /dev/loop0   
Label: none  uuid: 0a774d9c-b250-420e-9484-b8f982818c09
        Total devices 4 FS bytes used 28.00KB
        devid    4 size 1.00GB used 264.00MB path /dev/loop4
        devid    1 size 1.00GB used 268.00MB path /dev/loop0
        devid    2 size 1.00GB used 0.00 path /dev/loop1
        *** Some devices missing
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop1      3.0G   56K  1.5G   1% /mnt

Here again, removing a device is totally dynamic and can be done as an on-line operation! Note that when a device is removed, its content is transparently redistributed among the other devices.

Obvious points:

• ** DO NOT UNPLUG THE DEVICE BEFORE THE END OF THE OPERATION, DATA LOSS WILL RESULT**
• If you have used raid0 in either metadata or data at the BTRFS volume creation you will end in a unusable volume if one of the the devices fails before being properly removed from the volume as some stripes will be lost.

Once you add a new device to the BTRFS volume as a replacement for a removed one, you can cleanup the references to the missing device:

# btrfs device delete missing

Using a BTRFS volume in degraded mode

If you use raid1 or raid10 for data AND metadata and you have a usable submirror accessible (consisting of 1 drive in case of RAID1 or the two drive of the same RAID0 array in case of RAID10), you can mount the array in degraded mode in the case of some devices are missing (e.g. dead SAN link or dead drive) :

# mount -o degraded /dev/loop0 /mnt

If you use RAID0 (and have one of your drives inaccessible) the metadata or RAID10 but not enough drives are on-line to even get a degraded mode possible, btrfs will refuse to mount the volume:

# mount /dev/loop0 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

The situation is no better if you have used RAID1 for the metadata and RAID0 for the data, you can mount the drive in degraded mode but you will encounter problems while accessing your files:

# cp /mnt/test.dat /tmp 
cp: reading `/mnt/test.dat': Input/output error
cp: failed to extend `/tmp/test.dat': Input/output error

Playing with subvolumes and snapshots

A story of boxes….

When you think about subvolumes in BTRFS, think about boxes. Each one of those can contain items and other smaller boxes (“sub-boxes”) which in turn can also contains items and boxes (sub-sub-boxes) and so on. Each box and items has a number and a name, except for the top level box, which has only a number (zero). Now imagine that all of the boxes are semi-opaque: you can see what they contain if you are outside the box but you can’t see outside when you are inside the box. Thus, depending on the box you are in you can view either all of the items and sub-boxes (top level box) or only a part of them (any other box but the top level one). To give you a better idea of this somewhat abstract explanation let’s illustrate a bit:

(0) --+-> Item A (1)
      |
      +-> Item B (2)
      |
      +-> Sub-box 1 (3) --+-> Item C (4)
      |                   |
      |                   +-> Sub-sub-box 1.1 (5) --+-> Item D (6)
      |                   |                         | 
      |                   |                         +-> Item E (7)
      |                   |                         |
      |                   |                         +-> Sub-Sub-sub-box 1.1.1 (8) ---> Item F (9)
      |                   +-> Item F (10)
      |
      +-> Sub-box 2 (11) --> Item G (12)                    

What you see in the hierarchy depends on where you are (note that the top level box numbered 0 doesn’t have a name, you will see why later). So:

• If you are in the node named top box (numbered 0) you see everything, i.e. things numbered 1 to 12
• If you are in “Sub-sub-box 1.1” (numbered 5), you see only things 6 to 9
• If you are in “Sub-box 2” (numbered 11), you only see what is numbered 12

Did you notice? We have two items named ‘F’ (respectively numbered 9 and 10). This is not a typographic error, this is just to illustrate the fact that every item lives its own peaceful existence in its own box. Although they have the same name, 9 and 10 are two distinct and unrelated objects (of course it is impossible to have two objects named ‘F’ in the same box, even they would be numbered differently).

… applied to BTRFS! (or, “What is a volume/subvolume?”)

BTRFS subvolumes work in the exact same manner, with some nuances:

• First, imagine a frame that surrounds the whole hierarchy (represented in dots below). This is your BTRFS volume. A bit abstract at first glance, but BTRFS volumes have no tangible existence, they are just an aggregation of devices tagged as being clustered together (that fellowship is created when you invoke mkfs.btrfs or btrfs device add).
• Second, the first level of hierarchy contains only a single box numbered zero which can never be destroyed (because everything it contains would also be destroyed).

If in our analogy of a nested boxes structure we used the word “box”, in the real BTRFS word we use the word “subvolume” (box => subvolume). Like in our boxes analogy, all subvolumes hold a unique number greater than zero and a name, with the exception of root subvolume located at the very first level of the hierarchy which is always numbered zero and has no name (BTRFS tools destroy subvolumes by their name not their number so no name = no possible destruction. This is a totally intentional architectural choice, not a flaw).

Here is a typical hierarchy:

.....BTRFS Volume................................................................................................................................
.
.  Root subvolume (0) --+-> Subvolume SV1 (258) ---> Directory D1 --+-> File F1
.                       |                                           |
.                       |                                           +-> File F2
.                       |
.                       +-> Directory D1 --+-> File F1
.                       |                  |
.                       |                  +-> File F2
.                       |                  |
.                       |                  +-> File F3
.                       |                  |
.                       |                  +-> Directory D11 ---> File F4
.                       +-> File F1
.                       |
.                       +-> Subvolume SV2 (259) --+-> Subvolume SV21 (260)
.                                                 |
.                                                 +-> Subvolume SV22 (261) --+-> Directory D2 ---> File F4
.                                                                            |
.                                                                            +-> Directory D3 --+-> Subvolume SV221 (262) ---> File F5
.                                                                            |                  |
.                                                                            |                  +-> File F6
.                                                                            |                  |
.                                                                            |                  +-> File F7
.                                                                            |
.                                                                            +-> File F8
.
.....................................................................................................................................

Maybe you have a question: “Okay, What is the difference between a directory and a subvolume? Both can can contain something!”. To further confuse you, here is what users get if they reproduce the first level hierarchy on a real machine:

# ls -l
total 0
drwx------ 1 root root 0 May 23 12:48 SV1
drwxr-xr-x 1 root root 0 May 23 12:48 D1
-rw-r--r-- 1 root root 0 May 23 12:48 F1
drwx------ 1 root root 0 May 23 12:48 SV2

Although subvolumes SV1 and SV2 have been created with special BTRFS commands they appear just as if they were ordinary directories! A subtle nuance exists, however: think again at our boxes analogy we did before and map the following concepts in the following manner:

• a subvolume : the semi-opaque box
• a directory : a sort of item (that can contain something even another subvolume)
• a file : another sort of item

So, in the internal filesystem metadata SV1 and SV2 are stored in a different manner than D1 (although this is transparently handled for users). You can, however see SV1 and SV2 for what they are (subvolumes) by running the following command (subvolume numbered (0) has been mounted on /mnt):

# btrfs subvolume list /mnt
ID 258 top level 5 path SV1
ID 259 top level 5 path SV2

What would we get if we create SV21 and SV22 inside of SV2? Let’s try! Before going further you should be aware that a subvolume is created by invoking the magic command btrfs subvolume create:

# cd /mnt/SV2
# btrfs subvolume create SV21
Create subvolume './SV21'
# btrfs subvolume create SV22
Create subvolume './SV22'
# btrfs subvolume list /mnt  
ID 258 top level 5 path SV1
ID 259 top level 5 path SV2
ID 260 top level 5 path SV2/SV21
ID 261 top level 5 path SV2/SV22

Again, invoking ls in /mnt/SV2 will report the subvolumes as being directories:

# ls -l
total 0
drwx------ 1 root root 0 May 23 13:15 SV21
drwx------ 1 root root 0 May 23 13:15 SV22

Changing the point of view on the subvolumes hierarchy

At some point in our boxes analogy we have talked about what we see and what we don’t see depending on our location in the hierarchy. Here lies a big important point: whereas most of the BTRFS users mount the root subvolume (subvolume id = 0, we will retain the root subvolume terminology) in their VFS hierarchy thus making visible the whole hierarchy contained in the BTRFS volume, it is absolutely possible to mount only a subset of it. How that could be possible? Simple: Just specify the subvolume number when you invoke mount. For example, to mount the hierarchy in the VFS starting at subvolume SV22 (261) do the following:

# mount -o subvolid=261 /dev/loop0 /mnt

Here lies an important notion not disclosed in the previous paragraph: although both directories and subvolumes can act as containers, only subvolumes can be mounted in a VFS hierarchy. It is a fundamental aspect to remember: you cannot mount a sub-part of a subvolume in the VFS; you can only mount the subvolume in itself. Considering the hierarchy schema in the previous section, if you want to access the directory D3 you have three possibilities:

1. Mount the non-named subvolume (numbered 0) and access D3 through /mnt/SV2/SV22/D3 if the non-named subvolume is mounted in /mnt
2. Mount the subvolume SV2 (numbered 259) and access D3 through /mnt/SV22/D3 if the the subvolume SV2 is mounted in /mnt
3. Mount the subvolume SV22 (numbered 261) and access D3 through /mnt/D3 if the the subvolume SV22 is mounted in /mnt

This is accomplished by the following commands, respectively:

# mount -o subvolid=0 /dev/loop0 /mnt
# mount -o subvolid=259 /dev/loop0 /mnt
# mount -o subvolid=261 /dev/loop0 /mnt

The default subvolume

$100 questions: 1. “If I don’t put ‘subvolid’ in the command line, 1. how does the kernel know which one of the subvolumes it has to mount? 2. Does Omitting the ‘subvolid’ means automatically ‘mount subvolume numbered 0’?”. Answers: 1. BTRFS magic!  2. No, not necessarily, you can choose something other than the non-named subvolume.

When you create a brand new BTRFS filesystem, the system not only creates the initial the root subvolume (numbered 0) but also tags it as being the default subvolume. When you ask the operating system to mount a subvolume contained in a BTRFS volume without specifying a subvolume number, it determines which of the existing subvolumes has been tagged as “default subvolume” and mounts it. If none of the exiting subvolumes has the tag “default subvolume” (e.g. because the default subvolume has been deleted), the mount command gives up with a rather cryptic message:

# mount /dev/loop0 /mnt
mount: No such file or directory

It is also possible to change at any time which subvolume contained in a BTRFS volume is considered the default volume. This is accomplished with btrfs subvolume set-default. The following tags the subvolume 261 as being the default:

# btrfs subvolume set-default 261 /mnt

After that operation, doing the following is exactly the same:

# mount /dev/loop0 /mnt
# mount -o subvolid=261 /dev/loop0 /mnt

Deleting subvolumes

Question: “As subvolumes appear like directories, can I delete a subvolume by doing an rm -rf on it?”. Answer: Yes, you can, but that way is not the most elegant, especially when it contains several gigabytes of data scattered on thousands of files, directories and maybe other subvolumes located in the one you want to remove. It isn’t elegant because rm -rf could take several minutes (or even hours!) to complete whereas something else can do the same job in the fraction of a second.

“Huh?” Yes perfectly possible, and here is the cool goodie for the readers who arrived at this point: when you want to remove a subvolume, use btrfs subvolume delete instead of rm -rf. That btrfs command will remove the snapshots in a fraction of a second, even it contains several gigabytes of data!

An example: considering our initial example given above and supposing you have mounted non-named subvolume numbered 0 in /mnt, you can remove SV22 by doing:

# btrfs subvolume delete /mnt/SV2/SV22

Obviously the BTRFS volume will look like this after the operation:

.....BTRFS Volume................................................................................................................................
.
.  (0) --+-> Subvolume SV1 (258) ---> Directory D1 --+-> File F1
.        |                                           |
.        |                                           +-> File F2
.        |
.        +-> Directory D1 --+-> File F1
.        |                  |
.        |                  +-> File F2
.        |                  |
.        |                  +-> File F3
.        |                  |
.        |                  +-> Directory D11 ---> File F4
.        +-> File F1
.        |
.        +-> Subvolume SV2 (259) --+-> Subvolume SV21 (260)
.....................................................................................................................................

Snapshot and subvolumes

If you have a good comprehension of what a subvolume is, understanding what a snapshot is won’t be a problem: a snapshot is a subvolume with some initial contents. “Some initial contents” here means an exact copy.

When you think about snapshots, think about copy-on-write: the data blocks are not duplicated between a mounted subvolume and its snapshot unless you start to make changes to the files (a snapshot can occupy nearly zero extra space on the disk). At time goes on, more and more data blocks will be changed, thus making snapshots “occupy” more and more space on the disk. It is therefore recommended to keep only a minimal set of them and remove unnecessary ones to avoid wasting space on the volume. The following illustrates how to take a snaphot of the VFS root:

# btrfs subvolume snapshot / /snap-2011-05-23
Create a snapshot of '/' in '//snap-2011-05-23'

Once created, the snapshot will persist in /snap-2011-05-23 as long as you don’t delete it. Note that the snapshot contents will remain exactly the same it was at the time is was taken (as long as you don’t make changes… BTRFS snapshots are writable!). A drawback of having snapshots: if you delete some files in the original filesystem, the snapshot still contains them and the disk blocks can’t be claimed as free space. Remember to remove unwanted snapshots and keep a bare minimal set of them.

Listing and deleting snaphots

As there is no distinction between a snapshot and a subvolume, snapshots are managed with the exact same commands, especially when the time has come to delete some of them. An interesting feature in BTRFS is that snapshots are writable. You can take a snapshot and make changes in the files/directories it contains. A word of caution: there are no undo capbilities! What has been changed has been changed forever… If you need to do several tests just take several snapshots or, better yet, snapshot your snapshot then do whatever you need in this copy-of-the-copy :-).

Using snapshots for system recovery (aka Back to the Future)

Here is where BTRFS can literally be a lifeboat. Suppose you want to apply some updates via emerge -uaDN @world but you want to be sure that you can jump back into the past in case something goes seriously wrong after the system update (does libpng14 remind you of anything?!). Here is the “putting-things-together part” of the article!

The following only applies if your VFS root and system directories containing /sbin, /bin, /usr, /etc…. are located on a BTRFS volume. To make things simple, the whole structure is supposed to be located in the SAME subvolume of the same BTRFS volume.

To jump back into the past you have at least two options:

1. Fiddle with the default subvolume numbers
2. Use the kernel command line parameters in the bootloader configuration files

In all cases you must take a snapshot of your VFS root *before* updating the system:

# btrfs subvolume snapshot / /before-updating-2011-05-24
Create a snapshot of '/' in '//before-updating-2011-05-24'

There is no “better” way; it’s just a question of personal preference.

Way #1: Fiddle with the default subvolume number

Hypothesis:

• Your “production” VFS root partition resides in the root subvolume (subvolid=0),
• Your /boot partition (where the bootloader configuration files are stored) is on another standalone partition

First search for the newly created subvolume number:

# btrfs subvolume list / 
'''ID 256''' top level 5 path before-updating-2011-05-24

‘256’ is the ID to be retained (of course, this ID will differ in your case).

Now, change the default subvolume of the BTRFS volume to designate the subvolume (snapshot) before-updating and not the root subvolume then reboot:

# btrfs subvolume set-default 256 /

Once the system has rebooted, and if you followed the advice in the previous paragraph that suggests to create an empty file of the same name as the snapshot, you should be able to see if the mounted VFS root is the copy hold by the snapshot before-updating-2011-05-24:

# ls -l /
...
-rw-rw-rw-   1 root root    0 May 24 20:33 current-is-before-updating-2011-05-24
...

The correct subvolume has been used for mounting the VFS! Excellent! This is now the time to mount your “production” VFS root (remember the root subvolume can only be accessed via its identification number i.e 0):

# mount -o subvolid=0 /mnt
# mount
...
/dev/sda2 on /mnt type btrfs (rw,subvolid=0)

Oh by the way, as the root subvolume is now mounted in /mnt let’s try something, just for the sake of the demonstration:

# ls /mnt
...
drwxr-xr-x   1 root root    0 May 24 20:33 current-is-before-updating-2011-05-24
...
# btrfs subvolume list /mnt
ID 256 top level 5 path before-updating-2011-05-24

No doubt possible  Time to rollback! For this rsync will be used in the following way:

# rsync --progress -aHAX --exclude=/proc --exclude=/dev --exclude=/sys --exclude=/mnt / /mnt

Basically we are asking rsync to:

• preserve timestamps, hard and symbolic links, owner/group IDs, ACLs and any extended attributes (refer to the rsync manual page for further details on options used) and to report its progression
• ignore the mount points where virtual filesystems are mounted (procfs, sysfs…)
• avoid a re-recursion by reprocessing /mnt (you can speed up the process by adding some extra directories if you are sure they don’t hold any important changes or any change at all like /var/tmp/portage for example).

Be patient! The resync may take several minutes or hours depending on the amount of data amount to process…

Once finished, you will have to set the default subvolume to be the root subvolume:

# btrfs subvolume set-default 0 /mnt
ID 256 top level 5 path before-updating-2011-05-24

Now just reboot and you should be in business again! Once you have rebooted just check if you are really under the right subvolume:

# ls / 
...
drwxr-xr-x   1 root root    0 May 24 20:33 current-is-before-updating-2011-05-24
...
# btrfs subvolume list /
ID 256 top level 5 path before-updating-2011-05-24

At the right place? Excellent! You can now delete the snapshot if you wish, or better: keep it as a lifeboat of “last good known system state.”

Way #2: Change the kernel command line in the bootloader configuration files

First search for the newly created subvolume number:

# btrfs subvolume list / 
'''ID 256''' top level 5 path before-updating-2011-05-24

‘256’ is the ID to be retained (can differ in your case).

Now with your favourite text editor, edit the adequate kernel command line in your bootloader configuration (/etc/boot.conf). This file contains is typically organized in several sections (one per kernel present on the system plus some global settings), like the excerpt below:

set timeout=5
set default=0

# Production kernel
menuentry "Funtoo Linux production kernel (2.6.39-gentoo x86/64)" {
   insmod part_msdos
   insmod ext2
   ...
   set root=(hd0,1)
   linux /kernel-x86_64-2.6.39-gentoo root=/dev/sda2 
   initrd /initramfs-x86_64-2.6.39-gentoo
}
...

Find the correct kernel line and add one of the following statements after root=/dev/sdX:

rootflags=subvol=before-updating-2011-05-24
   - Or -
rootflags=subvolid=256

Applied to the previous example you will get the following if you referred the subvolume by its name:

set timeout=5
set default=0

# Production kernel
menuentry "Funtoo Linux production kernel (2.6.39-gentoo x86/64)" {
   insmod part_msdos
   insmod ext2
   ...
   set root=(hd0,1)
   linux /kernel-x86_64-2.6.39-gentoo root=/dev/sda2 rootflags=subvol=before-updating-2011-05-24
   initrd /initramfs-x86_64-2.6.39-gentoo
}
...

Or you will get the following if you referred the subvolume by its identification number:

set timeout=5
set default=0

# Production kernel
menuentry "Funtoo Linux production kernel (2.6.39-gentoo x86/64)" {
   insmod part_msdos
   insmod ext2
   ...
   set root=(hd0,1)
   linux /kernel-x86_64-2.6.39-gentoo root=/dev/sda2 rootflags=subvolid=256
   initrd /initramfs-x86_64-2.6.39-gentoo
}
...

Once the modifications are done, save your changes and take the necessary extra steps to commit the configuration changes on the first sectors of the disk if needed (this mostly applies to the users of LILO; Grub and SILO do not need to be refreshed) and reboot.

Once the system has rebooted and if you followed the advice in the previous paragraph that suggests to create an empty file of the same name as the snapshot, you should be able to see if the mounted VFS root is the copy hold by the snapshot before-updating-2011-05-24:

# ls -l /
...
-rw-rw-rw-   1 root root    0 May 24 20:33 current-is-before-updating-2011-05-24
...

The correct subvolume has been used for mounting the VFS! Excellent! This is now the time to mount your “production” VFS root (remember the root subvolume can only be accessed via its identification number 0):

# mount -o subvolid=0 /mnt
# mount
...
/dev/sda2 on /mnt type btrfs (rw,subvolid=0)

Time to rollback! For this rsync will be used in the following way:

# rsync --progress -aHAX --exclude=/proc --exclude=/dev --exclude=/sys --exclude=/mnt / /mnt

Here, please refer to what has been said in Way #1 concerning the used options in rsync. Once everything is in place again, edit your bootloader configuration to remove the rootflags/real_rootflags kernel parameter, reboot and check if you are really under the right subvolume:

# ls / 
...
drwxr-xr-x   1 root root    0 May 24 20:33 current-is-before-updating-2011-05-24
...
# btrfs subvolume list /
ID 256 top level 5 path current-is-before-updating-2011-05-24

At the right place? Excellent! You can now delete the snapshot if you wish, or better: keep it as a lifeboat of “last good known system state.”

Some BTRFS practices / returns of experience / gotchas

• Although BTRFS is still evolving, at the date of writing it (still) is an experimental filesystem and should be not be used for production systems and for storing critical data (even if the data is non critical, having backups on a partition formatted with a “stable” filesystem like Reiser or ext3/4 is recommended).
• From time to time some changes are brought to the metadata (BTRFS format is not definitive at date of writing) and a BTRFS partition could not be used with older Linux kernels (this happened with Linux 2.6.31).
• More and more Linux distributions are proposing the filesystem as an alternative for ext4
• Some reported gotchas: https://btrfs.wiki.kernel.org/index.php/Gotchas
• Playing around with BTFRS can be a bit tricky especially when dealing with default volumes and mount point (again: the box analogy)
• Using compression (e.g. LZO =>> mount -o compress=lzo) on the filesystem can improve the throughput performance, however many files nowadays are already compressed at application level (music, pictures, videos….).
• Using space caching capabilities (mount -o space_cache) seems to brings some extra slight performance improvements.
• There is very interesting discussion on BTRFS design limitations with B-Trees lying on LKML. We strongly encourage you to read about on

Deploying a Funtoo instance in a subvolume other than the root subvolume

Some Funtoo core devs have used BTRFS for many months and no major glitches have been reported so far (except an non-aligned memory access trap on SPARC64 in a checksum calculation routine; minor latest kernels may brought a correction) except a long time ago but this was more related to a kernel crash due to a bug that corrupted some internal data rather than the filesystem code in itself.

The following can simplify your life in case of recovery (not tested):

When you prepare the disk space that will hold the root of your future Funtoo instance (and so, will hold /usr /bin /sbin /etc etc…), don’t use the root subvolume but take an extra step to define a subvolume like illustrated below:

# fdisk /dev/sda2
....
# mkfs.btrfs /dev/sda2
# mount /dev/sda2 /mnt/funtoo
# subvolume create /mnt/funtoo /mnt/funtoo/live-vfs-root-20110523
# chroot /mnt/funtoo/live-vfs-root-20110523 /bin/bash

Then either:

• Set the default subvolume /live-vfs-root-20110523 as being the default subvolume (btrfs subvolume set-default…. remember to inspect the subvolume identification number)
• Use rootflag / real_rootfsflags (always use real_rootfsflags for kernel generated with Genkernel) on the kernel command line in your bootloader configuration file

Technically speaking, it won’t change your life BUT at system recovery: when you want to rollback to a functional VFS root copy because something happened (buggy system package, too aggressive cleanup that removed Python, dead compiling toolchain…) you can avoid a time costly rsync but at the cost of putting a bit of overhead over your shoulders when taking a snapshot.

Here again you have two ways to recover the system:

• fiddling with the default subvolume:
  • Mount to the no named volume somewhere (e.g. mount -o subvolid=0 /dev/sdX /mnt)
  • Take a snapshot (remember to check its identification number) of your current subvolume and store it under the root volume you just have just mounted (btrfs snapshot create / /mnt/before-updating-20110524) — (Where is the “frontier”? If 0 is monted does its contennts also appear in the taken snashot located on the same volume?)
  • Update your system or do whatever else “dangerous” operation
  • If you need to return to the latest good known system state, just set the default subvolume to use to the just taken snapshot (btrfs subvolume set-default <snapshotnumber here> /mnt)
  • Reboot
  • Once you have rebooted, just mount the root subvolume again and delete the subvolume that correspond to the failed system update (btrfs subvolume delete /mnt/<buggy VFS rootsnapshot name here>)

• fiddling with the kernel command line:
  • Mount to the no named volume somewhere (e.g. mount -o subvolid=0 /dev/sdX /mnt)
  • Take a snapshot (remember to check its identification number) of your current subvolume and store it under the root volume you just have just mounted (btrfs snapshot create / /mnt/before-updating-20110524) — (Where is the “frontier”? If 0 is mounted does its contents also appear in the taken snapshot located on the same volume?)
  • Update your system or do whatever else “dangerous” operation
  • If you need to return to the latest good known system state, just set the rootflags/real_rootflags as demonstrated in previous paragraphs in your loader configuration file
  • Reboot
  • Once you have rebooted, just mount the root subvolume again and delete the subvolume that correspond to the failed system update (btrfs subvolume delete /mnt/<buggy VFS rootsnapshot name here>)

Space recovery / defragmenting the filesystem

# btrfs filesystem defrag /mnt

You can still access the subvolume, even change its contents, while a defragmentation is running.

It is also a good idea to remove the snapshots you don’t use anymore especially if huge files and/or lots of files are changed because snapshots will still hold some blocks that could be reused.

SSE 4.2 boost

If your CPU supports hardware calculation of CRC32 (e.g. since Intel Nehalem series and later and AMD Bulldozer series), you are encouraged to enable that support in your kernel since BTRFS makes an aggressive use of those. Just check you have enabled CRC32c INTEL hardware acceleration in Cryptographic API either as a module or as a built-in feature

Recovering an apparent dead BTRFS filesystem

Dealing with a filesystem metadata coherence is a critical in a filesystem design. Losing some data blocks (i.e. having some corrupted files) is less critical than having a screwed-up and unmountable filesystem especially if you do backups on a regular basis (the rule with BTRFS is *do backups*, BTRFS has no mature filesystem repair tool and you *will* end up in having to re-create your filesystem from scratch again sooner or later).

Mounting with recovery option (Linux 3.2 and beyond)

If you are using Linux 3.2 and later (only!), you can use the recovery option to make BTRFS seek for a usable copy of tree root (several copies of it exists on the disk). Just mount your filesystem as:

# mount -o recovery /dev/yourBTFSvolume /mount/point

btrfs-select-super / btrfs-zero-log

Two other handy tools exist but they are not deployed by default by sys-fs/btrfs-progs (even btrfs-progs-9999) ebuilds because they only lie in the branch “next” of the btrfs-progs Git repository:

• btrfs-select-super
• btrfs-zero-log

Building the btrfs-progs goodies

The two tools this section is about are not build by default and Funtoo ebuilds does not build them as well for the moment. So you must build them manually:

# mkdir ~/src
# cd ~/src
# git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git 
# cd btrfs-progs
# make && make btrfs-select-super && make btrfs-zero-log

Fixing dead superblock

In case of a corrupted superblock, start by asking btrfsck to use an alternate copy of the superblock instead of the superblock #0. This is achieved via the -s option followed by the number of the alternate copy you wish to use. In the following example we ask for using the superblock copy #2 of /dev/sda7:

# ./btrfsck --s 2 /dev/sd7

When btrfsck is happy, use btrfs-super-select to restore the default superblock (copy #0) with a clean copy. In the following example we ask for restoring the superblock of /dev/sda7 with its copy #2:

# ./btrfs-super-select -s 2  /dev/sda7

Note that this will overwrite all the other supers on the disk, which means you really only get one shot at it.

If you run btrfs-super-select prior prior to figuring out which one is good, you’ve lost your chance to find a good one.

Clearing the BTRFS journal

This will only help with one specific problem!

If you are unable to mount a BTRFS partition after a hard shutdown, crash or power loss, it may be due to faulty log playback in kernels prior to 3.2. The first thing to try is updating your kernel, and mounting. If this isn’t possible, an alternate solution lies in truncating the BTRFS journal, but only if you see “replay_one_*” functions in the oops callstack.

To truncate the journal of a BTRFS partition (and thereby lose any changes that only exist in the log!), just give the filesystem to process to btrfs-zero-log:

# ./btrfs-zero-log /dev/sda7

This is not a generic technique, and works by permanently throwing away a small amount of potentially good data.

Using btrfsck

If one thing is famous in the BTRFS world it would be the so-wished fully functional btrfsck. A read-only version of the tool was existing out there for years, however at the begining of 2012, BTRFS developers made a public and very experimental release: the secret jewel lies in the branch dangerdonteveruse of the BTRFS Git repository hold by Chris Mason on kernel.org.

# git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
# cd btrfs-progs
# git checkout dangerdonteveruse
# make

So far the tool can:

• Fix errors in the extents tree and in blocks groups accounting
• Wipe the CRC tree and create a brand new one (you can to mount the filesystem with CRC checking disabled )

To repair:

# btrfsck --repair /dev/''yourBTRFSvolume''

To wipe the CRC tree:

# btrfsck --init-csum-tree /dev/''yourBTRFSvolume''

Two other options exist in the source code: –super (equivalent of btrfs-select-super ?) and –init-extent-tree (clears out any extent?)

Final words

We give the great lines here but BTRFS can be very tricky especially when several subvolumes coming from several BTRFS volumes are used. And remember: BTRFS is still experimental at date of writing 

Lessons learned

• Very interesting but still lacks some important features present in ZFS like RAID-Z, virtual volumes, management by attributes, filesystem streaming, etc.
• Extremly interesting for Gentoo/Funtoo systems partitions (snapshot/rollback capabilities). However not integrated in portage yet.
• If possible, use a file monitoring tool like TripWire this is handy to see what file has been corrupted once the filesystem is recovered or if a bug happens
• It is highly advised to not use the root subvolume when deploying a new Funtoo instance or put any kind of data on it in a more general case. Rolling back a data snapshot will be much easier and much less error prone (no copy process, just a matter of ‘swapping’ the subvolumes).
• Backup, backup backup your data! 

编译自：https://bash-prompt.net/guides/create-system-load/ 作者： Elliot Cooper
原创：LCTT https://linux.cn/article-9235-1.html 译者： DarkSun
本文地址：https://linux.cn/article-9235-1.html

2018-01-14 10:31

原创：LCTT https://linux.cn/article-9182-1.html 译者： kimii
本文地址：https://linux.cn/article-9182-1.html

2017-12-27 15:11    收藏: 1