在2013年，在一个新的Linux映像上仍然具有多个安装点是否有意义，还是将所有空间分配给/更有意义？
我希望避免重新启动以增加安装点的大小。我也希望监视单个安装架的空间。我宁愿知道整个服务器的驱动器空间使用率都超过70％，而不是处理单个安装点。
Answers:
当然，它仍然有用。您不希望失控的进程填充日志并导致/占用整个磁盘。另外，如果您使用的是LVM之类的产品，则可以在线扩展卷。
对于许多虚拟机，无论如何都将要分离IO。您可能希望将数据库放在单独的主轴上，而唯一的实现方法是为数据库的位置设置单独的安装点。除了数据库，如果您超出了原始设计的范围，它将为您提供更细致的灵活性。
简而言之，是的，在2013年仍然有充分的理由这样做。
/填满，它们将崩溃。
如今，我不会使用太多单独的安装架，但是可能有一些关键的安装架将有助于系统管理。
尤其是2或3。大小不一的 这取决于您使用的是什么。我会说只是/（相对稳定）和/ var（正在变化）。根据操作系统和磁盘的几何形状，可能还需要/ boot。/ tmp可能是安装程序设置的tmpfs挂载。
不断变化的卷（主要是/ var，但可能只是/ var / log和/ var / lib / mysql等）通常是您需要担心并计划扩展的。因此，如果可能，请使用lvm等使调整大小变得更容易。
是的，我仍然在虚拟机和安装点上使用多个分区来监视，安全和维护需求。
我不喜欢单一或有限安装点虚拟机（除非它们是一次性计算机）。我对待虚拟机的方式与对待物理服务器的方式相同。在可执行文件，数据分区，临时文件和日志存储的逻辑分离方面，使分区与某些Linux Filesystem Hierarchy Standard对齐仍然有意义。这也简化了系统维修。对于从模板派生的虚拟机和服务器尤其如此。
（顺便说一句，我也不喜欢虚拟机上的LVM ... 计划更好！！）
在我的系统中，我尝试执行以下操作：
/ 通常很小，不会增长很多。 /boot 大小可预测，并且增长受内核更新频率控制。 /tmp取决于应用程序和环境，但是可以适当调整大小。单独监视它有助于计量异常行为并保护系统的其余部分。/usr 应该是可预测的，包含可执行文件等。/var增长，但是数据流失的数量可以更小。很高兴能够单独计量。/data，但是如果这是一个数据库系统，则可能是/var/lib/mysql或/var/lib/pgsql...。请注意，它是一个不同的块设备/dev/sdb。这只是该虚拟机上的另一个VMDK，因此可以独立于包含实际OS分区的VMDK进行调整大小。# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 12G 2.5G 8.8G 23% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
/dev/sda1 291M 131M 145M 48% /boot
/dev/sda7 2.0G 68M 1.9G 4% /tmp
/dev/sda3 9.9G 3.5G 5.9G 38% /usr
/dev/sda6 6.0G 892M 4.8G 16% /var
/dev/sdb1 360G 271G 90G 76% /data
其中一些分区的分离使识别趋势和检测异常行为变得容易得多。例如4GB核心转储进来/var，一个过程耗尽/tmp，
正常
不正常。/var如果使用一个大/分区，则不容易检测到突然增加。
最近，我不得不为安全加固的VM模板应用一系列文件系统安装参数和属性（nodev，nosuid，noexec，noatime，nobarrier）。分区是对此的绝对要求，因为某些分区需要无法全局应用的特定设置。另一个数据点。
确保多个安装点仍然具有其优势，无论是否具有虚拟服务器。
但是，使用虚拟化，您可能还会使用虚拟机模板，对吗？您的监视系统，例如Nagios（带有NConf？）也支持模板吗？如果是这样，那么您只需要经历一次精神坐骑战斗。
返回主题。
我用这种方式分割我的系统：/，/home，/usr，/var，/tmp（可能还有一些其他的挂载点数据），但是这是矫枉过正和麻烦。如今，只有一个简单的OS映像/（也许带有一个单独的映像）/var是我的理想选择。然后，如果虚拟服务器需要更多的数据存储空间，那么我为其提供另一个磁盘映像，然后将其挂载到需要的位置。
/opt或者/tmp在单个分区设置下？
du -m --max-depth=4 / | sort -nr | head -n 30 | less会令人惊讶。并处于受控状态。在受监控的环境中，无论如何，您有多少个潜在的场所？/var/log，/tmp，/opt/*/log，也许是别的什么？不是太难。