☰

UNIX 与 Windows 文件系统；为什么 UNIX 为每个目录分配有限的空间？

tag-icon • tag-icon windows unix filesystems
UNIX 与 Windows 文件系统；为什么 UNIX 为每个目录分配有限的空间？

全部，

我终于开始了解 NIX 的复杂性，但有一件事我仍在试图弄清楚，那就是为什么 UNIX 将硬盘空间分配给其文件系统中的每个目录。

我在尝试在根目录中创建一个可以放置的新目录时发现了这一点ISO用于运行虚拟机

/iso/

如下所示使用 df 命令；有些目录比其他目录有更多的空间

例如 root 只有700兆分配给它，而 /export/home 有65GB

    /dev/fd            (fd                ):       0 blocks        0 files
/tmp               (swap              ): 7724392 blocks   576352 files
/var/run           (swap              ): 7724392 blocks   576352 files
/export/home       (/dev/dsk/c0d0s7   ):138187048 blocks  8350700 files
/mnt

我相信在 Windows 中不存在这样的事情；每个目录都会占用其当时所需的空间。

UNIX 以这种方式管理空间的优势是什么？在我看来，它似乎有点不灵活，或者也许我只是太习惯使用 Windows 了。

答案1

DF 不显示文件夹。
它显示分区以及它们在整个文件系统中如何“挂载”（链接）。

第一列是分区在文件系统中的位置。
第二列给出了分区本身的引用。
其他列显示了附加信息，例如已用/可用大小。

您混淆了文件系统和底层分区的固定大小与文件系统中的文件夹概念。

更复杂的是：其中一些分区是虚拟的，只存在于内存中（/proc，有时是/tmp），因此根本不与磁盘上的任何物理分区相关。

答案2

我相信您误解了这些文件系统的含义。在我的 Kubuntu 机器上，df输出结果如下（顺便说一下，该选项以单位而不是块为单位-h打印大小）：human

  $ df -h
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/sda1        28G  6,9G   20G  27% /
  none            4,0K     0  4,0K   0% /sys/fs/cgroup
  udev            2,9G  4,0K  2,9G   1% /dev
  tmpfs           585M  1,4M  584M   1% /run
  none            5,0M     0  5,0M   0% /run/lock
  none            2,9G  820K  2,9G   1% /run/shm
  none            100M   20K  100M   1% /run/user
  /dev/sda6       202G   96G   97G  50% /home

你的困惑源于你所说的finite space directories不是磁盘上真正的文件系统，而是虚拟文件系统，i.e.*Nix 的组成部分文件系统层次结构，它们直接托管在 PC RAM 中。RAM 文件系统直接托管在 PC 主内存中，以便以最快的速度访问它们，因此您可以在其中找到/tmp和/proc。它们具有确定的大小，因为 RAM 的容量有限，并且并非所有 RAM 空间都可以分配给这些文件系统。RAM 磁盘的使用不仅限于操作系统，也向（有能力的）用户开放：您可以在中了解如何生成这样的文件系统在此可访问的网页中. 还应该清楚的是，在不幸的假设下，即 RAM 中分配的空间不足，系统将扩展交换区域中的虚拟文件系统。

答案3

实际上，它更像是 Windows (控制/管理，相反）做事的方式不够灵活。

在 DOS 和 Windows（包括 Windows NT 系列，该系列衍生了 Windows NT 3.x、Windows 2000、Windows XP 和 Windows 8）中，直到最近，磁盘分区和文件系统之间才存在一对一映射。（这种情况因引入卷装入点在 Windows 2000 中，尽管这仍然是一个很少使用的功能，也许在特殊情况之外。

类 Unix 系统明确区分了包含文件系统的存储设备、文件系统本身和挂载点文件系统的可访问性。这是底层设计的一部分，每个部分都发挥着重要作用。

在 Windows 中，通常通过分区分配的驱动器号（例如，C:或E:）。在 *nix 中，文件系统通常通过目录路径访问（例如，/export/home可能相对于当前目录）。

后者更灵活，因为在一条路径中，有没有关于底层存储的编码假设。一个分区上的空间不足？只需将该分区上当前存在的大型文件系统移动到另一个分区，更新挂载表（在 Linux /etc/fstab 中，在其他 *nix 上可能有所不同）以将相关目录指向新的物理设备，然后就大功告成了。或者通过将大型目录移动到新存储设备上的文件系统将文件系统一分为二，然后再次更新挂载表。切换到基于 SAN 的存储架构而不是每个主机的存储？同样的事情。就用户而言，除了实际移动数据发生的短暂时间之外，这可以在不明显干扰任何其他事物的情况下完成。特别是在卷挂载点之前，在以 Microsoft 为中心的环境中很难做到这一点。

当您创建目录时，/isos您是在根文件系统内创建目录，因此根文件系统必须支持该目录中内容的存储。如果您后来意识到此存储不足，则可以采取措施缓解或纠正这种情况，而无需在逻辑上移动文件，方法是创建单独的文件系统并将其挂载到根目录中并将文件移动到/isos根目录中该文件系统的/isos当文件系统安装在那里时使它们可见。

请记住，Unix 是作为多用户系统设计的，而 Windows（以及 Windows 的许多底层设计选择）则将其血统追溯到本质上严格的单用户系统。虽然这种灵活性在单用户系统上可能不需要，但在多用户设置中确实有很大帮助。（管理员无需在终端室入口处贴出一张通知，说“大家好，以前在 D: 上的内容，除了 D:\STUFF，现在都在 Q: 上，除了 D:\GAMES 中的内容，现在在 R:\WASTE 下，D:\MATH 现在在 E:\ALGEBRA 下，哦，我希望我没有忘记任何东西”；只需将文件重新排列，但保持逻辑目录不变。）

相关内容