我们的用户经常要求共享磁盘空间与一组用户一起使用，以交换或处理某些文件。 为了能够利用配额pipe理，我们创build一个新的用户帐户（控制配额），并从该用户组访问该用户的家庭。 我其实不喜欢这种方法。 我们如何build立一个灵活的解决scheme，使我们能够根据需要为一些用户提供一定的空间，并启用配额控制？
（我想到的一个解决scheme是大量使用LVM来为每个组创build一个新的分区（lv），但是我不确定它将如何扩展。）
我是“软配额”的粉丝。 硬配额和磁盘限制可能会削弱工作能力，如果他们碰巧实际需要30G空间来做一些大型项目，比方说。 在我的公司，我们有一个非常简单的脚本，它抓住了AD的所有用户，SMB安装他们的主目录，并进行大小计算。 附加到这个脚本是一个标准的配额限制（2G为我们），以及一个例外列表。
如果他们违反配额，他们会和pipe理层一起收到一份电子邮件通知，说明他们目录的大小以及配额。
不适用于每个环境或每个规模，但是当您有一个严格的配额限制时，它会降低生产率。
根据我的经验，大问题是：
我们已经定义了“项目”目录，并使用XFS项目配额来强制配额。 我们同时使用软配额和硬配额，并且在达到软配额时通过电子邮件提醒用户。 这是使用XFS轻松实现的function。
权限似乎总是一个巨大的问题。 我们现在使用ACL来确保组中的所有成员都可以访问所有已创build的文件，但是当我们将目录共享给不理解这些ACL的计算机时，或者程序创build的文件具有明确的权限时，会出现问题。 我们最终得到的子目录没有正确的ACL，然后用户抱怨他们不能编辑其他人创build的组文件夹中的某些项目。 这导致每个人都得到了自己的一切，并运行chmod -R 777 * 。 似乎大多数人希望组文件夹具有一组同样适用于所有后代文件系统对象的权限。
为了执行此操作，我们有一个名为权限的cron脚本，该脚本定期遍历所有项目目录，并修复所有文件系统对象的权限（包括标准和ACL）。 一切都获得相同的权限级别（虽然它维护eXecutable位），权限是在版本控制的configuration文件中定义。 这给了我们很好的保证，用户不会在不知不觉中绕过访问控制来访问错误的人。
在我们的Mac OS X服务器上，这是相当容易的。 HFS具有可以覆盖所有后代文件系统对象的ACL的ACL。 更好的是，它们被应用在服务器端，所以不理解HFS ACL的客户端（例如linux NFS客户端）也能按预期工作。 我们只需在组目录本身定义ACL，并且它的所有内容始终可以统一到整个组。
另一个棘手的问题是谁最终负责存储在组/项目目录中的数据。 数据往往会积累和腐烂，因为没有一个人负责保持整洁。 当达到配额时，有时很难find合适的人来通知。 为了解决这个问题，我们试图指定一个用户作为每个目录的维护者。
我们为组共享数据使用了一个单独的分区。 然后，我们设置组配额，每个组有一个目录。 我们还将目录设置为setgid，所以新创build的文件将inheritance组的权限。 这可能不会形成一个完整的解决scheme，但可能是一个有用的开始。
如果可以摆动它，请使用Solaris（或OpenSolaris）计算机作为文件服务器。 ZFS和更高级的NFSv4 ACL比Posix权限，Posix ACL，LVM等要好得多。即使客户端不会说NFSv4，ACL仍然会被ZFS强制执行和传播，他们只需要pipe理从服务器。 在大多数情况下，这实际上可能更好，因为复杂性对于最终用户来说是隐藏的。
然后，您可以轻松地为每个操作组，项目或其他任何操作创buildZFS文件系统，并根据需要分配配额和配额策略。
这是迄今为止我所见过的最灵活的系统types，但当然不适用于任何环境。