小编Ned*_*d64的帖子

该设置是一个加密的 LVM 容器/PV，其中包含一些 ext4 分区。我将这些移动到一台新机器上，但磁盘上有更多空间。所以，我创建了一个更大的加密 LVM 容器/PV。我有dd旧容器的转储（保存 LVM PV 的整个 GPT 分区，仍然加密），但实际磁盘不见了。

我怎样才能最好地恢复数据，并能够在我这样做时调整（放大）分区的大小 - 或者至少在更大的 PV 内创建新的分区？

由于要在引导期间输入的加密密码的数量，新磁盘上应该仍然只有一个 PV。我已经搜索了一下，但没有找到这种情况的答案。

我有大量文件需要减小大小。我发现大多数（不是全部）文件都有一个结束部分，可以在不丢失信息的情况下进行剪切：

Data 1
Data 2
something_unimportant_here END DATA
Rubbish 1
Rubbish 2

如何通过删除包括“END DATA”在内的行和所有后续行，就地，仅更改包含该模式的文件，从而最大限度地减少对磁盘的写访问（许多，许多）来编辑文件（因此，全部）文件和慢速磁盘）。

如果可能，我想在文件中添加一个新的最后一行（我自己的结束标记），以便文件的语法保持正确——同样，仅在包含该模式的文件中。

我正在考虑使用ed，比如

echo ',s/END DATA/ ???? '\\n'q'\\n'wq' | ed "$file"

但似乎无法管理？？？部分更正。

预期输出：

Data 1
Data 2
NEW END

当我插入 USB 驱动器时，它会自动安装在/run/media/user/fslabel. 这是完成的，我猜是由一些 udev/dbus/thunar/nautilus/gvfs 或其他系统完成的，我觉得这很方便，不想恢复到由 root 手动安装。但是，我的默认挂载选项有问题：挂载了 vfat 驱动器，以便在所有常规文件上设置可执行标志。这是一个麻烦和安全问题，我希望禁用它。

如何设置系统范围的挂载选项，例如noexec对所有 vfat分区使用标志并禁用ext4用户空间程序/守护程序挂载分区？

几年前，我在不同的系统上尝试了一些非常耗时的事情，比如编辑一些udev或dbus规则（显然不是设计为手动编辑的文件），由于缺乏适当的文档和发行版之间的巨大差异，这是一项巨大的努力. 这是预期的和唯一的方法吗？如果是这样，有人可以告诉我要在哪里更改吗？

我在 XFCE 桌面上使用 Arch Linux、CentOS 和 openSUSE。自动挂载可能由 nautilus、thunar 或 dolphin 中的一个执行，在后台运行（或者可能是由这些启动的服务？！）。我不确定，因为它发生在后台。

我有多个共享主目录和数据目录的 GNU/Linux 安装。随着时间的推移，这些目录中的一些用户文件已收到组 ID 100（usersLinux 某些变体下的组），其他用户文件的组 ID 为1000（也是users其他变体下的组）。

现在我希望统一users所有发行版之间的组 ID，但我应该选择哪一个？

我记得有一个 Linux 标准，它给出了推荐的 GID 吗users？如果没有，有没有其他推荐或趋势（我不是问个人喜好）？

我正在尝试在运行 CentOS 8 (x86-64) 的无头服务器上创建并运行虚拟机。

安装必要的工具（例如 QEMU PC 系统模拟器）后，libvirt似乎缺少其主要可执行kvm文件：qemu/usr/bin/qemu-system-x86_64

在 CentOS 7 机器上（我已经这样做了十几次）我运行

root@centos7> rpm -qf /usr/bin/qemu-system-x86_64
qemu-system-x86-2.0.0-1.el7.6.x86_64

然而，CentOS 8 上没有这样的包：

root@centos8> dnf se qemu-system |& tail -1
No matches found.

这个可执行文件在哪里？CentOS 8 没有提供可用的 QEMU 系统吗？

root@centos8> dnf se qemu | uniq
Last metadata expiration check: 0:30:19 ago on (...)
========================= Name & Summary Matched: qemu =========================
qemu-guest-agent.x86_64 : QEMU guest agent
qemu-kvm-core.x86_64 : qemu-kvm core components
qemu-kvm-block-ssh.x86_64 : QEMU SSH block driver
qemu-kvm-block-curl.x86_64 …

我在这里读到，小条带大小对于 Linux 中的软件（也可能是硬件）RAID 5 和 6 不利。我看到的罕见基准完全同意这一点。
但大家给出的解释是这会引起更多的头部运动。我只是不明白小条纹如何导致更多的头部运动。

假设我们有一个包含 4 个本地 SAS 驱动器的 RAID 6 设置。

情况 1：我们写入 1 Gb 的顺序数据
程序要求内核写入数据，然后内核将其划分以匹配条带大小并计算要写入每个磁盘的每个块（数据和/或奇偶校验）。
内核能够同时写入 4 个磁盘（使用适当的磁盘控制器）。
如果写入的数据未与条带完全对齐，则内核只需在计算结果数据之前读取第一个和最后一个条带。所有其他条带只会被覆盖，而不关心以前的数据。
由于此计算的完成速度比磁盘吞吐量快得多，因此每个块都会直接写入每个磁盘上前一个块的旁边，而不会暂停。所以这基本上是对 4 个磁盘的顺序写入。
小的条带大小如何减慢这一速度？

情况 2：我们在随机位置写入 1,000,000 x 1 kb 的数据
1 kb 小于条带大小（常见条带大小当前为 512 kb）
程序要求内核写入一些数据，然后写入一些其他数据，然后再写入一些其他数据等等。对于每次写入，内核必须读取磁盘上的当前数据，计算新内容，然后将其写回磁盘。然后头部移动到其他地方，并且该操作会重复 999,999 次。
条带大小越小，读取/计算/写入数据的速度就越快。理想情况下，4 kb 的条带大小对于现代磁盘来说是最佳的（如果正确对齐）。

那么再一次，小条带大小如何减慢这一速度呢？