2

我想为我们正在开发的多用户 Web 应用程序实现每个目录的配额。问题是......我们已经为任何客户实现了一个文档管理器来存储他们自己的私人文档，但我们不想因为这个特性而耗尽空间，所以我们想给他们分配一个给定的限制。

由于似乎不存在在 Linux 中实现每个目录配额的标准方法（我知道，配额主要针对用户或组，但我们需要类似于 Windows Server 2008 R2 处理每个目录上的配额的方式基础）我选择使用“技巧”。我基本上是这样做的：

touch client1.ext3
dd if=/dev/zero of=./client1.ext3 bs=1024 count=16384
mkfs.ext3 ./client1.ext3
mount -o loop,rw ./client1.ext3 ./mountpoint

这只是一个代码示例，但这就是我的想法......我创建了分配给我的客户的虚拟“卷”，这样他们就可以存储他们的私人数据，如果他们需要更多，他们可以按存储量付费基础。

我看到的“问题”是我在我的 /dev 层次结构中只看到 8 个循环设备，我们目前有 17 个测试客户端用于我们的应用程序，因此当前存在的循环设备的数量不能满足我的需求。我知道您最多可以分配 256 个循环设备，直到内核版本 2.6.23，并且限制（从版本 2.6.24 开始）理论上不再存在，尽管我仍然有些担心。

老实说，我觉得用 1000 多个循环设备（在整个系统生命周期内根本不会卸载）填充 /dev 层次结构是非常错误的，而不是应该这样做的方式，但也许它是可行的中间 -长期解决方案，所以我的问题是：

  • 单个循环设备占用多少内存？
  • 如果分配了 256 个以上的循环设备，系统是否会崩溃或性能受到影响？
  • 我可以动态增加循环设备的数量吗？或者...
  • 如何在启动时预定义可用循环设备的数量？
4

3 回答 3

2

您描述的想法实际上是手工完成的“逻辑卷管理”（LVM）。如果您为此使用 LVM，您将获得“这是一个众所周知的标准”和“有很好的工具支持，包括在线调整大小等等”的双重好处。

于 2012-03-03T18:41:41.123 回答
1

在您的应用程序中跟踪存储配额，而不是在操作系统中。像这样创建大量的环回文件系统会浪费大量的存储空间，性能很差，扩展性也更差。

于 2012-03-03T18:29:29.297 回答
0

LVM 为您添加了静态分割的硬盘空间，并在其上创建了文件系统。如果是 ext4 或 xfs，则将可用的 pv 空间添加到 lv 中，并在分配给用户或组的动态设备上调整大小。不幸的是，如果您想减小尺寸（缩小），您必须离线执行此操作。首先你必须减小未挂载的文件系统大小，然后你必须减小 lv 大小。但这是有风险的，因为如果将 lv 减小到文件系统大小以下，则 fs 将被损坏。xfs 没有收缩功能，您只能增加它。

另一种方法是更高级的文件系统。这是 linux 完全支持的 btrfs，或者是作为 linux 内核模块实现的 zfs，而不是作为 fuse。使用这些文件系统，您可以创建逻辑子卷，并即时增加/减少最大可用空间。可用空间对所有卷都是公用的。在那些文件系统中，不可能将情人空间分配到其上的数据子卷中，那么这种方式不可能损坏 fs。不幸的是 zfs 作为模块你必须独立编译，因为没有官方的分布式 linux 内核支持这个 fs。但是你可以检查一下btrfs，它的功能现在已经非常接近 zfs 了，而且它是内核官方支持的。

顺便提一句。loop 基于主编号为 7 的块设备（请参阅 /dev/loop* 特殊块文件），并且有 64 个可用挂载点。也许这个数字更高，但我从未实现过。一些如何配置更多循环的方法在这里：http ://www.tldp.org/HOWTO/CDServer-HOWTO/addloops.html 。但是我的朋友告诉我一些技巧，您可以手动添加更多循环设备，它可以通过 mknod /dev/loop8 b 7 8 、 mknod /dev/loop9 b 7 9 等即时使用，当然无需更改模块。 conf 文件或类似文件，并在临时 udev 文件系统上创建，所有额外的循环都将丢失。

于 2017-01-10T11:28:00.500 回答