我经常想知道为什么对分区驱动器如此热衷，尤其是在 Unixy 操作系统（/usr、/var 等）上。这似乎不是 Windows 安装的常见主题。
似乎分区大大增加了填充一个分区的可能性，而其他分区则有大量可用空间。显然，这可以通过仔细的设计和规划来避免，但事情可能会发生变化。我在机器上经历过很多次，主要是在其他人设置的机器上，或者在相关操作系统的默认安装设置上。
我听到的另一个论点是它简化了备份。它如何简化备份？我还听说它提高了可靠性。再说一遍，怎么做？
我在磁盘存储中遇到的几乎 100% 的问题都与磁盘的物理故障有关。是否可以认为分区可能会加速硬件故障，因为在将数据从一个分区移动或复制到同一磁盘上的另一个分区时磁盘会抖动？
我并不想过多地摇摆不定，我只想看到一个古老的管理实践的理由。
我不认为设置大量分区是您应该为每个系统做的事情。就个人而言，在我的大多数 Linux 服务器上，我只设置了一个大分区。由于我的大多数系统都有小型驱动器并且是单一用途的并且服务于一些基础设施角色（dns、dhcp、防火墙、路由器等）。在我的文件服务器上，我设置分区以将数据与系统分开。
我高度怀疑一个分区良好的系统是否会增加失败的可能性。
将 /home/ 分开的原因之一是您可以重新安装操作系统，而不必担心丢失用户数据。除此之外，在安装所有内容时需要很多安全性，无论是只读的还是noexec。如果用户无法在可以编写代码的任何地方运行代码，那么攻击向量就会减少。
不过，我只会在公共机器上为此烦恼，因为一个分区中的磁盘空间用完但另一个分区中的磁盘空间不足是一个严重的烦恼。有一些方法可以解决这个问题，比如做软件 raid 或 ZFS，你应该能够轻松地动态调整分区大小，但我没有使用它们的经验。
您可以备份（通过 dumpfs 或类似方法）您想要的东西，而不是您不想要的东西。dump(1) 是比 tar(1) 更好的备份系统。
这也是分区的论据。用户填写他们的 homedirs 不会破坏服务器、关闭 Web 服务器、阻止日志发生、阻止 root 登录等。
它还允许您更透明地将数据的一部分（例如，/home）移动到另一个磁盘上：复制它，挂载它。如果您正在使用允许卷影副本/快照/任何东西的东西，您甚至可以实时进行。
我一直被教导将 /var 保存在单独的分区上，因此如果您得到一个失控的日志文件，您将阻塞单个分区而不是整个驱动器。如果它与系统的其余部分位于同一空间并且您 100% 填满整个磁盘，则它可能会崩溃并进行令人讨厌的恢复。
Zoredache 提出的所有论点都是有效的；有些人可能会对细节有些挑剔（如果系统首先存在的原因是在其他文件系统上，那么让机器运行得更快，这样你就可以做其他事情，而 fsck'ing 其他文件系统对你没有多大好处） ; 但是，它们都是事后证明。
在真正老式的时代，您没有将文件系统放在单独的分区上——您将它们放在单独的磁盘上，因为磁盘非常小。想想 10MB。(1) 所以你有一个很小的 / 分区、一个 /var 磁盘、一个 /usr 磁盘、一个 /tmp 磁盘和一个 /home 磁盘。如果您需要更多空间，则购买另一张磁盘。
然后“大”50MB 磁盘的成本开始低于月球计划，突然之间，将整个系统放在一个具有可用用户空间的磁盘上成为可能。
尽管如此，与计算机可能生成的磁盘相比，磁盘大小仍然很小，隔离 /var 和 /opt 和 /home 以便填充一个不会导致计算机崩溃仍然是一个好主意。
今天，在企业情况下，我不会对操作系统进行分区。数据被分区，特别是如果它是用户生成的；但通常这是因为它位于某种高速和/或冗余磁盘阵列上。但是 /var 和 /usr 都与 / 位于同一个分区中。
在家庭环境中，同样的事情 - /home 可能应该位于单独的磁盘/阵列上，以便可以安装/升级/破坏/修复所需的任何操作系统风格。
这样做的原因是因为无论你猜到你的 /var 或 /usr 或任何树可能有多大——你要么大错特错，要么荒谬地过度提交。我的一位老（呃）学校的同事发誓要进行分区，当他最终在我创建的系统上经历了 180 天的 fsck 时，我总是会感到悲伤。但在我的整个职业生涯中，我一只手可以数出某些东西被填满/导致系统瘫痪的次数，而我一只手可以数出今年到目前为止我一直盯着一个系统的次数决定 /var 永远不需要超过（比如说）1GB 并且是错误的，让我盯着系统其他地方的完整 /var 和 00 年代的免费 GB，所有这些都可能在月球上他们对我有好处。
在当今的大磁盘世界中，我认为没有任何真正的理由对 OS 树进行分区。用户数据，是的。但是 /var 和 /usr 和 /var/spool 等的单独分区等等等等？不。
(1) = 我知道只要选择那个大小，我就会让评论中有人说10MB？奢华。为什么我们的磁盘只是...
回复：
在 Linux 机器上，LVM（逻辑卷管理）用于防止这种情况。大多数文件系统允许调整大小（有些甚至在线）。我为不同的用途创建不同的分区并将它们格式化为不同的文件系统（即：xfs 用于我可以快速删除的大型下载文件）。需要更多的空间？挂载一个新驱动器，将数据移到其中，然后将其挂载到原来的数据位置。它对用户和应用程序完全无缝。
使用 LVM，您可以将磁盘或分区添加到卷组中，然后在该组中创建逻辑卷。如果您在卷组中保留可用空间，则可以增加正在填满的分区。如果文件系统支持它（ext3、ext4、reiserfs），您可以缩小您过度分配的分区。
例如：在 /dev/sda1 上创建一个引导分区 创建第二个（未格式化的）分区 /dev/sda2
当您在 /downloads 上需要更多空间时（安装文件系统时）：
你现在有一个 150GB 的下载分区。家里也一样。事实上，我今天刚刚调整了一个 ext4 lvm“分区”的大小。另一方面，逻辑卷并不是真正的分区，而您所说的分区大小不正确，这与我的个人经验相矛盾（麻烦多于其价值）。
传统的 Unix 分区方案无疑是一种老派的做法，它不像以前那么有用了。早在 Unix 系统正常运行时间以年为单位的时代，你有几十上百个用户在使用 shell，将 /usr 安装为只读是保护系统的有用方法。现在重新挂载文件系统来打补丁似乎更费力而且没那么有用。
在过去的美好时光里，在我的大学里，Unix 集群具有带有标准 unix 工具的只读文件系统，附加应用程序位于 /usr/local 中，这是一个 NFS 和后来的 AFS 文件系统。部分原因是方便……当您可以在高速、4Mb 或 10Mb 网络上运行应用程序时，谁还想在集群中的十几个机器上重新编译软件？今天，有了不错的软件包管理器和大量便宜的磁盘，这没什么大不了的。
我认为在 1999 年左右，在装有 Veritas Volume Manager 的 Sun 机器上，我的思维过程开始发生变化，这大大降低了移动磁盘的痛苦阈值。
今天，当我想到分区时，我想到的是数据保护和性能。说明性示例：
这些注意事项也适用于 Windows。我们有一个管理大约 40k 客户端的 SCCM 服务器。数据库和日志位于大型 IBM DS8000 磁盘上。软件包位于 EMC Celerra 上，带有大而慢的 SATA 磁盘，每 GB 成本降低 60%。
（假设有一个大磁盘可用，）我将
home和var放在单独的分区上以控制“失控 [用户|日志文件] 填满所有空间”的问题，并允许轻松升级操作系统而无需触及主页，但离开一起休息。在较旧的硬件上，有时需要有一个单独的
boot分区，以确保引导加载程序可以访问内核映像。我知道这个问题不是特定于操作系统的，对吧？
在 Windows 下，我倾向于给我的所有机器尽可能少的分区，但不少于两个 - SYSTEM 和 DATA。如果机器有两个物理磁盘，那么一个（较小的）将是 SYSTEM，另一个是 DATA。如果只有一个磁盘，我将它分成两个分区。
原因只有一个——当我需要重装机器的时候（而且会有这样的时候），我不用担心SYSTEM分区的内容——我只要对它做一个完整的格式化，然后一个干净安装。这当然意味着我的文档（最好是桌面）必须映射到 DATA 上的文件夹，但这很容易做到，尤其是在 Vista 和更高版本上。
我也尝试过制作更多的分区（如游戏、音乐、电影等），但这只会导致其中一些溢出到其他分区中，造成比秩序更多的混乱。
您提到一个磁盘已满，而另一个磁盘有空闲空间——这是我分区的原因之一——因为我可以确保某些分区不会被填满。尽管按照过去管理配额的方式，您必须在其他分区上为所有用户分配 0 配额，以确保他们在设法找到他们的目录时不会开始隐藏文件可以写信给。
至于简化备份——如果我知道每个分区的最大大小是多少，我可以确保它的大小正好适合单个磁带，并且可以在固定的时间内完成。
至于可靠性，我唯一能想到的就是监控——我可以更容易地看到给定分区何时增长超过应有的程度，并让我有理由对其进行调查。
... 现在，说了这么多，我们离每个用户在共享计算机上获得 20MB 小配额的日子还很远。一些旧习惯没有意义——但是当你有一个进程发疯并填充/var，而后者又填充/，事情就停止了，在生产机器上保护并不是那么糟糕.
对于家庭，我有分区，但这只是为了更容易管理已安装的操作系统。