About Apple File System Appleファイルシステムについて

Overview 概要

Apple File System replaces HFS Plus as the default file system for iOS 10.3 and later, and for macOS High Sierra and later. Apple File System offers improved file system fundamentals as well as several new features, including cloning, snapshots, space sharing, fast directory sizing, atomic safe-save, and sparse files. Apple File Systemは、iOS 10.3以降の、およびmacOS High Sierra以降の省略時のファイルシステムとして、HFS Plusを置き換えます。Apple File Systemは、改良されたファイルシステム原理、それだけでなく幾つかの新しい機能を、クローニング、スナップショット、スペース共有、高速ディレクトリサイジング、アトミックセーフセーブ、そしてスパースファイルを含めて提供します。

Using high-level APIs in Foundation, such as FileManager and FileHandle, to interact with files takes advantage of the new behavior provided by Apple File System automatically, without requiring changes your code. Foundationでの高水準API、たとえばFileManagerとFileHandleなどを使ってファイルと相互作用することは、Apple File Systemによって提供される新しい挙動を自動的に活用します、あなたのコードを変更する必要なしにです。

If you need to interact with the file system directly, without using any frameworks or the operating system, read Apple File System Reference. あなたがファイルシステムと直接に、何らかのフレームワークまたはオペレーティングシステムを使うことなしに相互作用する必要があるならば、Apple File System Referenceを読んでください。

Clones Reduce the Cost of Copying クローンはコピーの経費を減らします

A clone is a copy of a file or directory that occupies no additional space on disk. Clones let you make fast, power-efficient file copies on the same volume. The copyItem(at:to:) and copyItem(atPath:toPath:) methods of FileManager automatically create a clone for Apple File System volumes, as shown in the listing below. クローンは、ファイルまたはディレクトリのコピーです、それはディスク上でまったく追加的空間を占有しません。クローンは、あなたに高速で、省力化されたファイルコピーを同じボリューム上で行わせます。FileManagerのcopyItem(at:to:)とcopyItem(atPath:toPath:)メソッドは、自動的にクローンをApple File Systemボリュームに対して作成します、下のコード出力で示されるように。

let origin = URL(fileURLWithPath: "/path/to/origin")
let destination = URL(fileURLWithPath: "/path/to/destination")
do {
    // Creates a clone for Apple File System volumes, or makes
    // a copy immediately for other file systems.
    try FileManager.default.copyItem(at: origin, to: destination)
} catch {
    // ... Handle the error ...
}

Modifications to the data are written elsewhere, and both files continue to share the unmodified blocks. You can use this behavior, for example, to reduce storage space required for document revisions and copies. The figure below shows a file named “My file” and its copy “My file copy” that have two blocks in common and one block that varies between them. On file systems like HFS Plus, they’d each need three on-disk blocks, but on an Apple File System volume, the two common blocks are shared. データに対する修正は、どこか他で書き込まれます、そして両方のファイルとも修正されないブロックの共有を継続します。あなたはこの挙動を使用して、たとえば、書類の修正版およびコピーに必要とされるストレージスペースを減らすことができます。下の図は、 “My file” と名前を付けられたファイルとそれのコピー “My file copy” を示します、それは共通の２つのブロックとそれらの間で異なる１つのブロックを持ちます。HFSプラスのようなファイルシステム上では、それらは３つのディスク上ブロックをそれぞれが必要とするでしょう、しかしApple File Systemボリューム上では、２つの共通ブロックは共有されます。

Free Space Is Shared Between Volumes 空きスペースはボリューム間で共有されます

Many files systems, including HFS Plus, support only a single volume per partition. Because free space can’t be shared across partitions, each volume’s size is set when partitioning the storage device, and each volume can only grow into its available free space. In contrast, Apple File System supports multiple volumes within a single partition, which allows all of those volumes to share their free space. All of the volumes in an Apple File System partition can grow and shrink independently; space that’s freed when one volume shrinks can be used when another volume grows. 多くのファイルシステムは、HFSプラスを含めて、パーティションごとにただ１つのボリュームだけをサポートします。空きスペースはパーティションを越えて共有できないことから、各ボリュームのもつ大きさはストレージデバイスを分割している時に設定されます、そして各ボリュームはそれの利用可能な空きスペースに成長することだけが可能です。対照的に、Apple File Systemは、複数のボリュームを単一のパーティション内にサポートします、それは、それらボリュームの全てにそれらの空きスペースを共有させます。あるApple File Systemパーティションの中のボリュームの全ては、独立して増大および縮小できます；１つのボリュームが縮小する時に解放されるスペースは、別のボリュームが増大する時に使われることができます。

Each volume in the container can use the shared free space, so they all include that amount when reporting the available free space. For example, when you call attributesOfFileSystem(forPath:) method of FileManager, the amount that’s reported includes all of the shared free space. コンテナの中の各ボリュームは、その共有空きスペースを使用できます、それでそれらは全てその量を利用可能な空きスペースを報告する時に含みます。たとえば、あなたがFileManagerのattributesOfFileSystem(forPath:)メソッドを呼び出す時、報告される量は共有空きスペースの全てを含みます。

if let attributes = try? FileManager.default.attributesOfFileSystem(forPath: "/") {
    let availableFreeSpace = attributes[.systemFreeSize] 
}

Computing the sum of each volume’s available free space isn’t a reliable way to determine the total free space within a partition. In general, check whether the space required to perform a particular operation is available on the volume, rather than trying to calculate the partition’s total free space. 各ボリュームのもつ利用可能な空きスペースの合計を計算することは、あるパーティション内の合計空きスペースを決定する信頼できる方法ではありません。一般に、特定のオペレーションを実行するのに必要とされるスペースがそのボリューム上で利用可能であるかどうかを調べてください、パーティションのもつ合計空きスペースを計算しようと試みるのではなく。

Sparse Files Don’t Allocate Empty Blocks スパースファイルは空のブロックを割り当てません

In file systems that support sparse files, including Apple File System, on-disk blocks are allocated only when those blocks are actually written to. This behavior lets files that contain blank sections, such as disk images and database dumps, be saved on disk more efficiently. スパースファイルをサポートするファイルシステムでは、Apple File Systemを含めて、ディスク上のブロックはそれらブロックが実際に書き出される時にのみ割り当てられます。この挙動は、空白セクションを含むファイル、たとえばディスクイメージそしてデータベースダンプなどが、ディスク上により効率的に保存されるようにします。

When you use the FileHandle class to create a new write handle, a sparse file is created automatically. For example, if you write a block of data, then seek one block by calling seek(toFileOffset:), and then write another block, the data stored on disk is organized as follows: あなたがFileHandleクラスを使って新しい書き出しハンドラを作成する場合、スパースファイルは自動的に作成されます。たとえば、あなたがデータのあるブロックを書き出し、それから１つのブロックをseek(toFileOffset:)を呼び出すことによってシークする、そしてそれから別のブロックを書き出すならば、ディスク上に格納されるデータは以下のように組織されます：

HFS Plus and other formats that don’t support sparse files allocate three blocks for the file, one for each block that was written, and one empty block in the middle. With support for sparse files, only two blocks are allocated, and the empty block is omitted. HFSプラスおよびスパースファイルをサポートしない他のフォーマットは、３つのブロックをそのファイルに対して割り当てます、書き出されたブロックそれぞれに対して１つ、そして真ん中に１つの空のブロック。スパースファイルに対するサポートで、２つのブロックだけが割り当てられます、そして空のブロックは省略されます。

Because the sparse file in the Apple File system example above doesn’t contain a blank second block on disk, writing to the second block later results in blocks that are out of order, as shown in the figure below. High-level APIs like FileHandle handle this fragmentation for you, and the performance loss due to fragmentation isn’t usually significant. 上のApple File Systemの例でのスパースファイルがディスク上で空白の２番目のブロックを含まないことから、２番目のブロックに後で書き出すことは順番のおかしいブロックという結果になります、下の図で示されるように。FileHandleのような高水準APIは、この断片化をあなたの代わりに取り扱います、そして断片化のための性能低下は普通は重大ではありません。

You can’t use FileHandle to create a sparse file from an existing file that has blank data already stored on disk. あなたは、FileHandleを使って、空白データが既にディスク上で格納されてしまっている既存のファイルから、スパースファイルを作成できません。