Talk:Apple File System

Copyrighted work?

This article definitely deserves an entry, but most of it seems ripped from the Apple Developer page. #!/bin/DokReggar -talk 15:49, 14 June 2016 (UTC)

Yes, the article is largely plagiarism. This must be removed.–Totie (talk) 00:29, 15 June 2016 (UTC)

Vaporware?

It seems that the filesystem is announced for next year. Given the fact that it takes 10 years to make a new filesystem usable in real life, I cannot understand the hype for a filesystem that promises less features than ZFS implemented 15 years ago. Schily (talk) 08:35, 15 June 2016 (UTC)

This is not vaporware. It's available to developers now with macOS Sierra Beta 1. It was announced on June 13 2016 and will be available to the public next year. The hype is about macOS finally getting first party support for a FS that has many of the features of ZFS Ccunning (talk) 12:24, 15 June 2016 (UTC)

Seeing how APFS is now the default file system on macOS High Sierra, I think we can safely conclude it's not vaporware. —Zenexer [talk] 20:12, 25 May 2018 (UTC)

CNIDs are 60 bit wide, not 64 bit.

"The statement "APFS supports 64-bit inode numbers" is technically incorrect, as the upper 4 bits are used as flags in the "fs_file" (= catalog) tree. Sadly, Apple's own docs haven't clarified that yet, and my own research hasn't been published, yet. There's a paper that clarifies this, but it's behind a paywall: [the APFS file system]. So I guess I cannot simply change the article or I'll get blamed for posting original research. Meh, not a serious issue, anyway. Tempel (talk) 18:21, 23 September 2017 (UTC)

This paper seems to indicate that they're 56 bits, where the most significant byte is the record type. —Zenexer [talk] 20:09, 25 May 2018 (UTC)

After further review of the paper by Hansen and Toolan, as well as Apple's documentation, I don't think it's appropriate to update the values on this page yet, especially since it would have a cascading effect on more significant properties like maximum file size. Hansen and Toolan indicate that the format changed (I believe prior to the first stable release) to include the record type (8 bits) in the 64-bit field that also holds the CNID. If I understand correctly, this means the actual maximum number of files is much lower, limited by the maximum number of blocks (2⁵⁶ or 2⁵⁵), but the number of possible inodes remains 2⁶⁴. Apple does differentiate between the two limits. As Apple hasn't acknowledged these changes as of May 25, 2018, and no further public research mentions the issue, we'll need to wait for a reliable secondary source publish research on the matter. A primary source is insufficient for this purpose. It may be appropriate to add a tag such as {{Dubious}}, {{Disputed inline}}, or {{Under discussion inline}}, but I'll let someone with more knowledge on the issue make that decision. —Zenexer [talk] 21:41, 25 May 2018 (UTC)

Compression or not?

The article is confusing (to me at least), it says "Transparent compression Yes (same as in HFS+)" and also under Limitation states "and does not support compression yet." — Preceding unsigned comment added by 213.80.106.33 (talk • contribs) 12:29, October 1, 2017 (UTC)

Updated the article with a source. AlistairMcMillan (talk) 19:32, 1 October 2017 (UTC)

Removed this from the article...

" Similar to LVM and Apple's Fusion Drive feature, an APFS container can be either a single physical partition or built from two partitions on separate drives."

I can't find anything in the documentation that suggests an APFS container can be spread across multiple devices. Please feel free to correct me if I'm wrong. AlistairMcMillan (talk) 17:36, 9 October 2017 (UTC)

Limitations of using APFS with Time Machine

The article currently states "…APFS is not yet an option for its backup volumes (as of macOS 10.13 High Sierra)." The Apple articles themselves are not clear on this topic. "Use a shared folder with Time Machine" [1] states that APFS is required for sharing a folder for Time Machine use (i.e. backing up multiple Macs to one folder), while "Disks you can use with Time Machine" [2] says "Time Machine can’t back up to an APFS-formatted disk." I suppose the article can't be updated until Apple gets their act together, but this is a fairly important point for admins hoping to set up a server as centralized backup. Xmarc999 (talk) 01:59, 21 March 2018 (UTC)

Time machine external volumes currently requires hard links for directories. This is a feature which was in HFS+ - but not most other modern file systems (including APFS) do not support. Apple's solution for time machine backups to non-HFS+ volumes is to use a writable disk image formatted HFS+.

There is also Time Machine over SMB

Local time machine snapshots were changed to support APFS when it became the default filesystem.

--Alksol (talk) 21:23, 26 September 2019 (UTC)

Indexed Directory Files

Does APFS bring indexed directory files to Apple devices? That is, directory information is stored in a indexed/hashed structure so that referencing files is almost instantaneous, even if the directory contains thousands of entries (as opposed to older filesystems where directory information is stored as an array and lookup times expand as number of entries grows).

I cannot see in information from Apple if APFS implements this feature. For comparison, see HTree Indexed Directories in Ext4. — Preceding unsigned comment added by 75.69.183.24 (talk) 20:53, 2 April 2018 (UTC)

HFS+ doesn't have directory files in the sense of files that have lists of names of files in the directories they belong to; instead, it had a huge B-tree, the catalog, indexed by a combination of file name and directory cnode (inode) number. This paper, "Decoding the APFS file system", suggests that APFS may be similar, although it refers to 10.12-era APFS, not High Sierra HPFS.

So, traditionally, "Apple devices" already had an indexed structure for looking up files by name - the catalog, which is a B-tree. APFS might continue that behavior. Guy Harris (talk) 21:33, 2 April 2018 (UTC)

Yes, both HFS+ and APFS use B-trees for indexing. —Zenexer [talk] 20:01, 25 May 2018 (UTC)

Hardlink to directories

The Article says: "This is in line with many other modern file systems"

I can't recally any. Neither NTFS, nor ReFS or ext4, btrfs, XFS nor ZFS do not have this feature. What mysterious modern filesystems are we talking about here? Afair AFS is the only one that can't do that

One problem with discussing file system features and characteristics is that the on-disk data structure may support capabilities that the file system implementation, or the APIs and kernel frameworks into which the implementation plugs, don't support.

Just about every UN*X file system has an on-disk data structure can support hard links to directories; however, at least some implementations either forbid it at the kernel VFS/IFS/whatever layer or in the file system implementation, or they require root privileges. I don't know whether Windows allows it at either of those layers or requires special privileges to do so.

So which modern implementations don't disallow it (other than HFS+ on versions of macOS that support Time Machine)? Guy Harris (talk) 23:31, 1 August 2018 (UTC)

APFS and appleRAID

Is it worth mentioning in the article that while APFS is supported on appleRAID devices, it isn't bootable, and existing HFS+/Core Storage appleRAID volumes cannot be converted to APFS (they need to be erased)? -- Haravikk (talk) 11:05, 4 August 2019 (UTC)

Limitations on magnetic drives

According to a thread on discussions.apple.com, MacOS does not allow magnetic drives to be used, hence the error: An internal error has occurred. : (-69626) after which, the drive will no longer be visible in MacOS until after being block erased on the command line. — Preceding unsigned comment added by 2003:a:c7f:6a00:3d02:bf93:409b:e8e9 (talk) 09:53, 10 December 2022 (UT) (UTC)

What is the URL of that thread? Guy Harris (talk) 10:55, 10 December 2022 (UTC)