当我将文件复制到时C:\...\Downloads\
,C:\...\Desktop\
它会立即发生,但如果我复制同一个文件(1.12 GB),则D:
需要相当长的时间。为什么会这样?
答案1
首先,你的核心问题是:
为什么在同一磁盘上跨分区复制需要时间?
下文将详细介绍,但从文件系统的角度来看,具有多个分区的单个磁盘不是“同一个磁盘”。从文件系统的角度来看,分区只是另一个“物理磁盘”,即使它只是较大的父物理磁盘上“逻辑上”分配的空间,其中有两个分区:
- 磁盘有分区,
- 分区有文件系统。
- 文件系统有文件。
请阅读以获得更多详情。
注意:我使用 Linux/Unix/Mac OS X 术语,因为这是我的核心专业知识,但基本概念适用于 Windows 以及任何操作系统。
为什么操作系统/内核不简单地将分配给该文件的字节/扇区/地址指针/任何内容的信息从一个文件系统表移动到其他分区的文件系统表?
这是因为控制和管理哪些扇区与哪些文件相连的 inode 表是每个磁盘、每个分区构造的。
因此,当您从中复制某些内容时,
C:
发生C:
的所有事情都是在驱动器上编辑 inode 条目C:
以指示同一驱动器上文件的新路径C:
。但是,当您从 复制某些内容
C:
到时D:
,必须复制数据,并且必须在D:
驱动器上创建一个新的 inode 条目。
假设您想知道为什么不将所有驱动器数据都保留在主C:
驱动器上,而是在每个设备、每个分区上进行操作?那么,当该驱动器或分区移动到另一台机器时会发生什么?D:
如果没有分配表数据,驱动器看起来就像是空的和未使用的空间。如果驱动器C:
在这种情况下崩溃,您不仅会丢失驱动C:
器,还会丢失与驱动器相关的更深层次的文件系统信息D:
。
您还对问题进行了编辑,以说明这一点:
我认为分区是逻辑上的而不是物理上的。
是也不是。分区合乎逻辑在分区表一侧。但在文件系统级别,文件系统看到的是分区就像另一个物理磁盘一样。
你还问了这个问题:
那么为什么操作系统或文件系统控制器不简单地将这些元数据复制
helloKitty.txt
到其他分区表呢?
它做将元数据从一个地方复制到另一个地方。但它也会复制实际文件数据,因为D:
在从 复制之前, 上的数据不存在。并且它复制的元数据仅限于有关文件内容的基本信息,因为当从磁盘/分区复制到磁盘/分区C:
时,字节和扇区数据会发生变化。C:
D:
字节的指针不会改变,它们是绝对的,因为分区是逻辑的而不是物理的。
在分区的上下文中,分区是“逻辑的”。存储在该分区上的文件系统中的数据在分区表中的各个文件的数据上下文中不是“逻辑的”。分区就是这样的——根据维基百科的定义— 描述如下;重点是我的:
磁盘分区是将硬盘驱动器 (HDD) 划分为多个逻辑存储单元(称为分区)的操作,将一个物理磁盘驱动器视为多个磁盘,以便每个分区可以使用不同的文件系统。
答案2
文件系统不仅仅是每个文件内容的地址。它还必须跟踪分区的哪些部分未分配(“可用空间”),以及总共有多少可用空间。如果分区中的文件系统C:
要在分区中存储一些文件数据D:
,它必须首先查看文件系统D:
的结构以找到一些可用空间,并且必须将该空间标记为在文件系统中已分配,D:
以便数据不会被在中创建的其他文件覆盖D:
。稍后,当您删除似乎在文件系统中的文件时C:
,它必须D:
再次进入文件系统以将该空间标记为可用。
错误检查可能会出现问题:通常,如果某个空间被标记为已分配,但实际上并非文件系统目录结构中任何文件的一部分,则这被视为错误。一致性检查器(例如 Windowschkdsk
或 Linux/Unix fdisk
)会将该空间标记为可用,或创建映射到该空间的文件,以便人们可以检查数据并手动删除它。但如果有问题的数据实际上是其他文件系统中某个文件的一部分,则会导致该空间被标记为可用(立即,或者当有人删除“恢复”的文件时),而仍有文件正在使用它。
安全地跨文件系统边界分配文件需要两个文件系统永久“了解”彼此的结构,以至于它们可能只是一个跨越多个分区的文件系统。有些文件系统实际上支持这一点:参见zfs
和btrfs
。它们的作用类似于文件系统内置的 RAID:它们可以使多个分区(甚至多个磁盘上的分区)显示为单个逻辑驱动器。但分区和磁盘相互依赖;您不能只取一个并单独使用它。
答案3
从这个角度来看,不同的分区就像不同的磁盘。
每个分区的块都是连续分配的,您建议的是磁盘自动重新分区,将属于一个分区的扇区分配给另一个分区。
这种方法很容易出错,会降低磁盘性能并破坏日志记录等其他功能。