The EFI jumpstart is particularly clever. A straightforward recipe for locating and verifying the file system driver, and then once executed the UEFI pre-boot environment can fully navigate an APFS volume.
Apple File System Reference [pdf]
41–50 of 67 posts
Re: Apple File System Reference [pdf]
#42Earlier quoted context omitted.
> I fear this is too little, too late to have iDefrag make a comeback Defragging has been snake oil for more than a decade, anything that hastens it’s demise is a good thing.
My computer (macOS Sierra, HFS (Journaled)) has 2x spinning drives of 3TB, and operations are noticeably quicker after an overnight defragmentation run, which I do twice a year or so. Anecdata, granted - but it works for my situation.
If it works for you, then great, but here's an article from almost 10 years ago where Apple discourages defragging[1]. There's a bunch of other articles with more specifics showing that advanced defrag features from the 90s were built into the OS years ago[2].
[1] https://support.apple.com/en-us/HT1375 (last updated 2010) [2] http://osxbook.com/software/hfsdebug/fragmentation.html (from 2004)
Re: Apple File System Reference [pdf]
#43This seems like it's probably enough to re-implement APFS on non-Mac platforms; in fact, the about page (page 6) says as much. Kudos to Apple for providing the information. It's a hell of a lot better than reverse engineering the thing (see how many years it took to get NTFS down...)
Likely enough to create third-party disk recovery utilities.
From the second paragraph of the PDF:
"This document is for developers of software that interacts with the file system directly, without using any frameworks or the operating system—for example, a disk recovery utility or an implementation of Apple File System on another platform."
Re: Apple File System Reference [pdf]
#44One of my long-time favourite macOS applications -- iDefrag -- had support withdrawn shortly after APFS appeared. Reasons cited were lack of an APFS spec and increased System Integrity Protection. I fear this is too little, too late to have iDefrag make a comeback. I understand defragmenting an SSD typically does more harm than good [edit: and I only defrag spinning drives), but nothing touched it for effectiveness o…
HFS+ has had on-the-fly defrag for ages now. Did you have issues with it? What kind of files do you work with?
Here's the essential business logic specification for HFS+ automatic de-fragmentation, for the curious.
It's actually quite a clever spec, because it takes advantage of existing efforts to read fragmented files to perform the majority of the de-fragmentation process.
I'm not sure if this spec applies to APFS or for SSDs. (With SSDs you're generally better off not defragmenting most of the time, because the performance penalty is far lower, but the write amplification has consequences.)
——————
When a file is opened on an HFS+ volume, the following conditions are tested:
If the file is less than 20 MB in size
If the file is not already busy
If the file is not read-only
If the file has more than eight extents
If the system has been up for at least 3 mins
http://osxbook.com/software/hfsdebug/fragmentation.html
——————
Re: Apple File System Reference [pdf]
#45The EFI jumpstart is particularly clever. A straightforward recipe for locating and verifying the file system driver, and then once executed the UEFI pre-boot environment can fully navigate an APFS volume.
Uhhh, personally I'd prefer that UEFI stay away from the OS particulars. But anyway, afaik Windows' boot code had about the same feature―at least it certainly did in regard to the chipset drivers, the result being IIRC that the OS wouldn't boot if you moved the partitions a bit.
Re: Apple File System Reference [pdf]
#46Earlier quoted context omitted.
> I fear this is too little, too late to have iDefrag make a comeback Defragging has been snake oil for more than a decade, anything that hastens it’s demise is a good thing.
My computer (macOS Sierra, HFS (Journaled)) has 2x spinning drives of 3TB, and operations are noticeably quicker after an overnight defragmentation run, which I do twice a year or so. Anecdata, granted - but it works for my situation.
Given that macOS automatically defragments sub-20MB files on the fly (which covers 99% of the files which affect perceived system performance) I'd wager money that your experience is 100% placebo.
I know from personal experience how powerful this placebo effect can be.
Re: Apple File System Reference [pdf]
#47I’m still sad that this filesystem does not contain file data checksums. It looks like we will be stuck with it for some years to come.
Care to enlighten ignorant me why we would want that?
I've recently listened through an old-but-good episode of the Hypercritical podcast with John Siracusa's informative rant about this very topic: http://5by5.tv/hypercritical/56
Re: Apple File System Reference [pdf]
#48fonts?
Should be San Francisco.
Every time I see the San Francisco font mentioned anywhere, I don't think of Apple's rather lovely neo-grotesque, but rather Apple's original San Francisco. (Which is also lovely, in an oh cool, this 1984 era computer has a variety of fonts kind of way.)
Re: Apple File System Reference [pdf]
#49Earlier quoted context omitted.
Care to enlighten ignorant me why we would want that?
Simple, to help prevent “bit rot”. The problem is exacerbated further in that many of us treat cloud sync services as backup, which they arguably aren’t - they can inconveniently just spread the decay. I’d also hoped that a next generation file system from Apple would have had more to say on this topic, but it seems like features that promote their iOS device agenda took front seat over less “sexy” features like data…
Might it not be the case that combating bit rot is best done at higher layers of the stack similar to how it is best done at levels higher than the IP layer in a networking stack?
For example, data painstakingly entered by the user a character at a time with a keyboard might deserve more redundancy than for example a movie downloaded by iTunes.
Re: Apple File System Reference [pdf]
#50The EFI jumpstart is particularly clever. A straightforward recipe for locating and verifying the file system driver, and then once executed the UEFI pre-boot environment can fully navigate an APFS volume.
Uhhh, personally I'd prefer that UEFI stay away from the OS particulars. But anyway, afaik Windows' boot code had about the same feature―at least it certainly did in regard to the chipset drivers, the result being IIRC that the OS wouldn't boot if you moved the partitions a bit.
The pre-boot environment needs to find the kernel and initramfs somehow. My guess for how Apple is booting from APFS, now that it's all APFS, without a separate recovery partition? They've got this minimalist EFI jumpstart code in the firmware, it loads the EFI file system driver for APFS, and now it can locate the bootloader, kernel, and kext cache.
For a long time Apple has had an HFS+ driver baked into the firmware. The way APFS is implemented with EFI jumpstart, they've got much less filesystem code in firmware.