- 3 兼容性
- ▪ 类 Unix 操作系统
- ▪ 微软视窗
- 4 碎片化
HFS+
编辑文件系统 HFS++ 或 - 更常见 - HFS+ 是 HFS 的进一步发展。 首字母缩写词代表分层文件系统。 它于 1998 年 1 月 19 日与 Mac OS 8.1 一起推出,长期以来一直是运行 Mac OS X 的 Macintosh 计算机(自 2012 年起称为 OS X,自 2016 年起称为 macOS)和 iOS 设备(iPhone、iPad、iPod、 Apple TV 和 Apple Watch)并可用于所有内部和外部存储媒体。 在 Mac OS X 本身中,它被称为 Mac OS Extended,其前身 HFS 被称为 Mac OS Standard。
与 FAT16/32 相比,HFS+ 的分配单元更小——这可以带来更高的分区效率或分区管理和访问速度。
HFS+ 的继任者是 2016 年推出的 Apple 文件系统 (APFS)。
HFS+变体
编辑HFS+ 有多种变体,其中一些可以组合使用。 为了完整起见,较旧的 HFS 也按原样列在此处,或者在 Mac OS X 上的“磁盘工具”中可供选择。 一些旧版本在新版本的 OS X/macOS 中不再可用。
Mac OS Standard 旧的分层文件系统,自 1986 年以来可用。 Mac OS Extended 新的 HFS+ 文件系统于 1998 年 1 月 19 日随 Mac OS 8.1 一起引入。 它是 Mac OS 8.1 到 9.2.2(最后一个经典 Mac OS 版本,直到 2001)和 Mac OS X 到 10.2(Jaguar,2002)的默认文件系统。Mac OS 扩展(日志式)也称为 jHFS+或 HFS+J,首次在 Mac OS X Server 10.2.2(2002 年,基于“Jaguar”)中引入,并成为桌面版 Mac OS X Panther(10.3,2003 年)的标准配置。 日志不是文件系统本身的一部分,而是在操作系统中以两个常规文件.journal 和.journal_info_block 的形式实现为虚拟文件系统(VFS),因此文件系统本身可以与或集成没有日记。 旧版本的 Mac OS/ Mac OS X 也可以使用相同的文件系统,但没有 Journal.Mac OS Extended(日志式,区分大小写)这个变体也在 Mac OS X Panther (10.3, 2003) 中引入。 操作系统对文件名中的大小写字母进行严格区分,也称为区分大小写。 此变体使用不同的分区标识符,也称为 HFSX。 这可以防止分区(以及文件系统)被安装在较旧的不兼容版本的 Mac OS/Mac OS X 下,因为这可能导致数据丢失。在这种区分大小写的变体中,HFSX 在被 APFS 取代之前iOS 设备上的默认文件系统。
除了 HFSX 变体之外,文件系统(其驱动程序)在默认情况下不会区分 HFS+ 文件名中的大小写字母,例如 例如,filename.ext(xxx个大写字母)表示与 filename.ext(全部小写)相同的文件。 规范化(大小写字母的转换,Unicode 的 NFD 规范化)发生在文件系统驱动程序中。
在 2006 年从 PowerPC 转向 Intel 架构后,HFS+ 仅用于日志版本。 与免费文件系统 ext3/ext4、XFS 和 ReiserFS 或 Microsoft 的商业 NTFS 一样,它比不使用日志记录的文件系统(FAT16 和 FAT32、ext2、HFS 等)更稳定。
分区标识符
在经典 Mac OS 和 Mac OS X 的 PowerPC 版本上,HFS 和 HFS+ 在 Apple 分区映射 (APM) 中使用相同的分区标识符 Apple_HFS。 另一方面,在 HFSX 变体中,标识符 Apple_HFSX 用于兼容性原因,因此较旧的操作系统不会无意中集成更现代(不兼容)的 HFS+ 变体,这可能导致系统不稳定和数据丢失。 这是 i.a. 这是区分大小写的 HFSX 版本的情况,但不是日志版本。
由于切换到英特尔处理器架构 IA-32 2006,GUID 分区表 (GPT) 被用作分区表。 旧的 HFS 分区不再显示在其中 - GUID 为 48465300-0000-11AA-AA11-00306543ECAC 的 HFSX 是 HFS-Plus 文件系统的标准 GPT 标识符。
RAID 和 FileVault 分区在 GUID 分区表 (GPT) 中具有不同的分区 GUID,就像 Apple 分区映射 (APM) 中的 RAID 分区一样。 这些分区类型也可以包含 HFS-Plus 文件系统,但不是必须的。
兼容性
编辑类 Unix 操作系统
在 Linux 发行版下,如果内核支持 hfsplus 文件系统,通常只需挂载即可读写 HFS/HFS+他们支持; 否则软件包 hfsutils(仅限 HFS)和 hfsplus 可用于后续安装。 可能需要安装 hfsprogs 或禁用文件系统日志记录以支持写入。 BSD系统也有相应的软件包。 这意味着如果安装了适当的内核支持,Unix/Linux 系统可以读取磁盘上的数据。
微软视窗
HFS+ 只能在附加软件的帮助下由基于 NT 的 Windows 操作系统使用。 Mac OS X Snow Leopard(10.6,2009)附带的 Boot Camp 3.0 提供了读取 HFS+ 文件系统的能力。
Windows 上的 HFS(+) 免费软件
- catacombae 的 HFSExplorer(需要 Java SE Runtime Environment 5.0 或更高版本)
Windows 上 HFS(+) 的专有软件
- Acute Systems 的 TransMac
- Mediafour 的 MacDrive
- Paragon Software Group 的 HFS+ for Windows
- DataViz 的 MacOpener(已停止开发)
- DiskInternals Research 的 Windows 版 Linux Reader™
Mac OS X/经典
Mac OS X 上的 Classic 环境需要使用 HFS+ 格式化的系统分区,不支持 UFS 文件系统。
碎片化
编辑HFS 和 HFS+ 旨在找到xxx的可用磁盘空间块来存储文件。 只有当一个文件放不下xxx的空闲内存块时,才会将文件拆分(分片),将尚未写入的部分存储在另一个块中。
这种方法假设文件的大小在写入时是事先已知的。 这种情况在 Mac OS X 上很常见,因为用于处理文档的系统库的设计方式通常是自动更新文件:保存更改时,文档的当前版本将同时写入一个新文件go,然后删除早期版本并将文件名转移到新文件中。
此外,Mac OS X 会尽可能避免重复使用已删除文件的已释放内存块。 此外,从 Mac OS X 10.2(“Jaguar”,2002 年)开始,免费块借记被推迟以将多个小块的预留合并为一个大的连续块的单一借记。
如果文件增长缓慢,则这种碎片避免是无效的,即在初始创建文件后稍后附加更多块。 从 Mac OS X Panther (10.3, 2003) 开始,操作系统因此也可以在运行时进行碎片整理(动态碎片整理)。
打开文件时,会检查文件是否被分成八个以上的部分。 如果是这种情况并且以下所有条件也适用,则将文件移动到足够大的空闲内存区域,从而进行碎片整理:
- 该文件只能由单个进程打开。
- 它在可写媒体上。
- 文件大小不超过 20 MiB。
- 文件在最后一分钟内没有被修改。
- 操作系统已运行至少三分钟。
Mac OS X 10.3 版使用的另一种方法(Panther,2003)是对频繁使用的文件进行自动分组(自适应热文件聚类):通过持续维护对每个文件的读取访问频率的统计数据来识别 Mac OS X 采用使用最频繁的文件并将它们移动到文件系统中位于核心元数据后面的区域。 在此移动过程中,文件会进行碎片整理并放置在 HFS 文件系统最常用元素的附近,从而xxx限度地减少磁头移动。 文件的使用强度是通过将过去 60 小时的观察窗口内读取的字节数除以文件的总大小来确定的。 文件系统总容量的0.5%作为这些文件的存储区域。 此区域中的文件数量限制为最多 5,000 个,并且只有 10 MiB 或更小的文件才会参与该过程。
其他碎片整理方法不是 Mac OS X 的一部分。Apple 建议不要使用程序进行后续碎片整理,因为它通常不值得使用。
内容由匿名用户提供,本内容不代表vibaike.com立场,内容投诉举报请联系vibaike.com客服。如若转载,请注明出处:https://vibaike.com/358207/