问题标签 [btrfs]

对于 btrfs 和其他使用 B-Tree 数据结构的文件系统，它们是为每个文件实现一个 B-Tree 还是为整个文件系统实现一个 B-Tree？这些 B-Trees 的关键和价值是什么？

我有两个内核：默认 4.4.26 和 4.4.26 with this patch。我应该在我的 btrfs 分区上运行什么样的测试或基准来查看应用上述补丁的性能提升？

在我的 linux 内核驱动程序中，我需要将 struct inode 转换为 struct btrfs_inode。
为了做到这一点，我查看了btrfs_getattr的实现。

代码很简单：

为了编译，我必须在函数顶部添加标题：

问题是什么 ？
我必须手动下载并包含 ctree.h 和 btrfs_inode.h，它们没有在 kernel-headers 包中提供。
在我编译驱动程序的每个平台上，我都有针对发行版/内核版本的特定 VM，因此在每个 VM 上，我通常会下载内核头文件包，并且一切都可以完美编译。

btrfs 是在内核 3.0 以上引入的。
btrfs 标头不应该在那里吗？它们存在于另一个包中吗？也许 fs-headers 或类似的东西？

谢谢

在对 BTRFS 手册页进行了大量测试和挖掘之后，我需要一些 Linux / BTRFS 人员的帮助。

我有一个 java 应用程序，它使用 java MappedByteBuffer 实用程序将数据文件写入磁盘。这是应用程序在写入磁盘时使用约 16000 字节的字节缓冲区。当一个新文件被写入时，它会创建一个缓冲区大小的临时文件，并且由于 mem 映射文件的 java 实现，代码不会显式关闭文件。相反，我们调用 Linux 的 drop_caches 来强制未使用的内存映射刷新到磁盘。

• 在 EXT4 上，这些文件会自动关闭并正确调整文件大小。
• 在 BTRFS 上，这些文件保持约 16000 字节，并且丢失了一些数据（可能是分页问题）
• 在 BTRFS 上，当我删除这些文件并且软件重新运行并再次创建文件时，每次都会出现相同的问题，并且修改的日期来自最初创建文件的时间

服务器信息： 我们在最新的 centos 7.2 上运行，并且是最新的补丁

• 操作系统 Centos 7 x64（内核 3.10.0-514.10.2.el7.x86_64）
• btrfs-progs v4.4.1
• Java 1.8.0_111

进行的测试

• 我们有一个在 Ext4 上运行的副本服务器，这个问题没有发生

• 我们目前正在使用 COW 和压缩，所以我尝试禁用它们，重新启动，删除旧数据并重新启动软件。问题依旧出现

• 我还尝试禁用space_cache，恢复，我还尝试使用flushoncommit设置commit = 5 ...这也无助于非关闭文件/不正确的修改日期

我已经阅读并且我相信理解了关于 using 的 docker 页面btrfs，尤其是这个

我的问题很简单，我需要能够导航（例如使用 cd 和 ls，但任何其他方式都可以），上面的链接称为附加到给定容器的Thin R/W 层。

我需要这个的原因是，我使用了一个我自己没有构建的图像 - 即 jupyter/scipy-notebook:latest - 我可以看到每个容器开始时对整体磁盘使用有大约 100-200 Mb 的影响，即使容器中不应该发生任何事情。

所以我怀疑会创建一些相当冗长的日志，我需要稍微安静一下；然而，整个 union fs 是巨大的——大约 5Gb 大——所以它会极大地帮助我只导航特定于一个容器的数据，这样我就可以查明问题。

我正在使用 Debian 发行版。我编写了一个实现快照轮换的备份 bash 脚本，它在从 shell 以交互方式调用它时就像一个魅力，但在从 cron 作业（root 用户）调用时失败。在脚本中的几个地方，我以这种方式生成目标路径字符串，示例：

或者

在第一种情况下，我创建了第一个每日快照，在第二种情况下，我删除了最后一个快照，该数字存储在 NUM_BAK 变量中。像往常一样，脚本文件以：

但是我注意到，当交互式调用时"$BASENAME-1"，当$BASENAME是“/mnt/backup/daily”时，最终字符串变为/mnt/backup/daily-1，当在 cron 中执行时，生成的字符串变为/mnt/backup/daily-没有最终数字。

crontab 行是：

我尝试了不同的解决方案。

1) 将 crontab 条目更改为：

2）添加crontab，首先是cron条目，这个（如建议here）：

我不是 shell 专家，我首先将所有这些 bash 脚本更改为更“确定性”的 python 脚本，我想了解问题出在哪里。

编辑（感谢您的建议）：我创建了一个专注于字符串替换的备份脚本的精简版本。 但是问题已经消失了。我必须将问题追溯到神秘的交互。当我有更多证据时，我会更新这个问题。

我通过比较从 500,000 个目录和只有 100 个文件的目录读取文件的速度来测试这一点。结果：两者都同样快。

测试细节：我创建了一个包含 500,000 个文件的目录for x in {1..500000}; do touch $x; done，运行time cat test-dir/some-file并将它与另一个只有 100 个文件的目录进行比较。它们的执行速度都一样快，但可能在重负载时存在差异，或者 ext4 和 btrfs 足够聪明，我们不再需要内容可寻址路径？

使用内容可寻址路径，我可以将 500,000 个文件分发到多个子目录中，如下所示：/www/images/persons/a/1/john.png /www/images/persons/a/2/henrick.png ..../ www/images/persons/b/c/frederick.png ...

500,000 个文件通过 nginx 提供给 UA，所以我想避免延迟，但也许这与 ext4 或 btrfs 不再相关？

我想在我的服务器上使用 btrfs 作为文件系统，并且在所有最坏的情况下我仍在研究它。

目前我想测试raid系统崩溃，我想测试的条件是：

1. 如果我的磁盘坏了，如何更换它
2. 如果我不能替换它，如何保存我的数据
3. 如果不小心我（或我的团队）格式化了其中一个磁盘，如何修复它
4. 如果不小心我的一个磁盘被盗了（我认为这种情况是不可能的，只是在最坏的情况下），如何更换它

对于我上面写的所有问题，我只能回答我的两个问题。

1. 第一个答案是，我可以replace在拔出损坏的磁盘之前使用方法。
2. 回答第二个，我可以插入外置硬盘，然后安装它，我可以使用restore方法保存我的数据

对于另一个问题，我没有测试它。

对于第 3 和第 4 个问题（如果我用另一个磁盘替换它），我尝试使用mount -o degraded但我无法安装它，它显示错误wrong fs type, bad option, bad superblock on /dev/sdb。我试图用balance方法重新平衡它，但我无法安装它。

拜托，我需要回答我的问题 3 和 4。

我已经格式化了一个加密磁盘，其中包含一个带有 btrfs 系统的 LVM。

所有超级块似乎都被破坏了；btrfs-progs 工具再也找不到根树，并且手术刀、binwalk、foremost 和 co 只返回废料。文件系统位于 ssd 上并使用 -o compression=lzo 挂载。

我到底有多烂？有机会恢复一些文件吗？有没有一种可行的方法来手动重建超级块？用 xxd 检查原始图像没有给我一个可读的单词。

我设法解密了 LV 并将其添加到图像中。我能做些什么？

我在 Ubuntu Server 16.04 上安装 Snapper( http://snapper.io/ ) 时遇到了一些困难。

当我按照Snapper for Ubuntu 16.04 的说明进行操作时，出现以下错误：

（download.opensuse.org/repositories/filesystems:/snapper/xUbuntu_16.04 libsnapper 0.5.1 协议“http”在 libcurl E 中不受支持或禁用：无法获取）

（download.opensuse.org/repositories/filesystems:/snapper/xUbuntu_16.04/./amd64/libsnapper_0.5.1_amd64.deb 协议“http”在 libcurl 中不受支持或禁用）

这似乎适用于 Ubuntu 16.04 桌面版。我可以让它为服务器工作吗？？？