I wonder how much of that is simply played podcast episodes getting deleted. I noticed that a bunch of mine were deleted, presumably due to a (new, I believe) setting to "Delete Played Episodes" which was set to ON (which is NOT what I would have chosen; I prefer more control). This setting is available at the app level (in Settings > Podcasts) & at the individual podcast level.
Update on iPhone 6 64GB was about 25 mins (after download of update).
Free storage went from 17.3GB to 19.0GB.
I seem to have also a better battery life.
They didn't fix though the bug I had, that when taking a pic directly from the stand-by screen, in landscape mode, doesn't rotate the UI and the pic is saved as portrait instead.
To the author, this has nothing to do with the size of the OS, which is probably larger. it is likely because the phone underwent cleaning of caches, logs etc. Try this, take a phone which is almost full, try to rent a large movie in iTunes, voila more space, like magic.
I wonder if some of the APFS features are designed to support FoundationDB. Fast cloning with spill-over updates seem a natural for a performant, fault-tolerant, distributed db -- as do the non-Posix directory manipulation features.
If so, we could see massive Apple servers -- if only for Apple internal use... And they could run on ARM CPUs, too.
To the author, this has nothing to do with the size of the OS, which is probably larger. it is likely because the phone underwent cleaning of caches, logs etc.
That would explain the increase in "available", but maybe not the increase in "capacity" as noted in the illustration. I've always thought that "capacity" being less than the 256GB advertised reflected the OS size...if so, the OS is smaller now...? But I'm sure Soli will counter with that explanation about...whatever that is he's been trying to explain (to me, among others) for years!
Or, it could be that the "gains" are illusory - when I plug-in my iPhone to my MBAir to do a backup, the 'capacity' and the 'available' readings shown are very different from those on the phone itself. Maybe iOS10.3 just doesn't count very well.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
It's more common on RAM. Reboot, folks!
Yeah, wasn't improvement of SSD endurance one of the reasons Apple acquired Anobit:
Anobit is a fabless semiconductor company based in Israel which makes a key component that improves the performance of NAND flash memory chips, which are used in iPhones, iPads, and iPods. As Robin wrote when the rumors first surfaced:
Anobit provides flash storage solutions for enterprise and mobile markets, based on its proprietaryMSP (which stands for ‘Memory Signal Processing’) technology. Its solutions are designed to improve the speed, endurance and performance of flash storage systems while driving down the cost. Anobit’s technology is comprised of signal processing algorithms that compensate for physical limitations of NAND flash, the company claims.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
It's more common on RAM. Reboot, folks!
One additional thing for rabid "bit-rottweilers" to consider: If bit-rot was such a perversive issue with modern SSDs, and Apple is the largest consumer of NAND, which they use in every device with an OS X variant, then why did they not consider addressing this widespread issue in their new file system?
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
1) That article is from June 2016, right after it was announced at WWDC.
2) As of June 2016, APFS did have checksums, but it ensures metadata integrity, not user data.
3) Regardless of whether one thinks ZFS is better than APFS or not is irrelevant since no version of OS X supports ZFS. All that matters is whether APFS is better than HFS+.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
It's more common on RAM. Reboot, folks!
One additional thing for rabid "bit-rottweilers" to consider: If bit-rot was such a perversive issue with modern SSDs, and Apple is the largest consumer of NAND, which they use in every device with an OS X variant, then why did they not consider addressing this widespread issue in their new file system?
Especially since the aforementioned FoundationDB extensively uses SSDs for performance which requires
durable writes/reads for ACID transactions. Likely, Anobit resolved any durability problems with SSDs -- and APFS provides capabilities that exploit the use of durable SSDs by FoundationDB.
It may be revealing to look at the timelines of Apple's acquisitions and developments:
07-2010 Swift Development began
12-2011 Anobit acquired
--- 2014 APFS Development began
06-2014 Swift Beta appears
03-2015 Foundation DB acquired
06-2016 APFS Beta
03-2017 APFS replaces HFS+ in iOS
03-2017 Swift 3.1 Stable release
I don't have any citations, but I strongly suspect these events and technologies are interrelated -- and can be deployed on ARM and Intel x86.
Here's an interesting blog post that may explain some of the storage reclamation on iDevices:
One cool thing is that now uploading Swift Apps to the device is much faster than before because it doesn't need to re-upload libSwift and other frameworks, because APFS on iOS 10.3
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
1) That article is from June 2016, right after it was announced at WWDC.
2) As of June 2016, APFS did have checksums, but it ensures metadata integrity, not user data.
3) Regardless of whether one thinks ZFS is better than APFS or not is irrelevant since no version of OS X supports ZFS. All that matters is whether APFS is better than HFS+.
AFICT, APFS does not currently support checksums on user data to allow backward compatibility with HFS+. It also allowed iDevices to upgrade from HFS+ to APFS by leaving the user data in place and only adding new APFS metadata -- a big advantage with the limited storage on iDevices.
I suspect that a future APFS release will implement these checksums and allow the user to implement it with a download-convert-upload process.
To the author, this has nothing to do with the size of the OS, which is probably larger. it is likely because the phone underwent cleaning of caches, logs etc.
That would explain the increase in "available", but maybe not the increase in "capacity" as noted in the illustration. I've always thought that "capacity" being less than the 256GB advertised reflected the OS size...if so, the OS is smaller now...? But I'm sure Soli will counter with that explanation about...whatever that is he's been trying to explain (to me, among others) for years!
Or, it could be that the "gains" are illusory - when I plug-in my iPhone to my MBAir to do a backup, the 'capacity' and the 'available' readings shown are very different from those on the phone itself. Maybe iOS10.3 just doesn't count very well.
I believe Capacity refers to the formatted volume (the physical device storage capacity subtracting the EFI partition map and other overhead) and Available shows the Capacity minus the OS and other content stored. So a reduction in OS or cache files wouldn't affect Capacity (which was about half of the total gains we saw upon upgrading).
Also: iOS and macOS present volume capacity in different terms that are (of course) equal. iOS uses binary (base 2, 1024) and macOS uses decimal (1000).
So in iOS, 1GB refers to ~1.074 billion bytes, meaning a "32GB" device is reported as having about 28GB.
In macOS, the same 32GB volume would be listed as 32GB because it counts 1GB as 1 billion bytes.
You can count to 16 in different base systems using different numbers but it's still the same 16 things:
The 10.3 update saved me a whopping 10GB of space. I had 102GB used on my 128GB iPhone7. Now I have 91GB available space. At first I thought it was because my photo library and music library hadn't finished downloading, but the restore is done and the storage on my phone matches the storage taken up in Photos and iTunes on my MacBook.
I haven't noticed any performance benefits yet, but it's only been 24 hours. But that 30GB of available space is nice. I can't wait to see how this optimization benefits gaming and photo/video editing in iOS11. I'm honestly hoping the embedded encryption features of APFS finally convince Apple to build a real file explorer/finder into iOS which would make it finally useful for business.
To the author, this has nothing to do with the size of the OS, which is probably larger. it is likely because the phone underwent cleaning of caches, logs etc.
That would explain the increase in "available", but maybe not the increase in "capacity" as noted in the illustration. I've always thought that "capacity" being less than the 256GB advertised reflected the OS size...if so, the OS is smaller now...? But I'm sure Soli will counter with that explanation about...whatever that is he's been trying to explain (to me, among others) for years!
Or, it could be that the "gains" are illusory - when I plug-in my iPhone to my MBAir to do a backup, the 'capacity' and the 'available' readings shown are very different from those on the phone itself. Maybe iOS10.3 just doesn't count very well.
I believe Capacity refers to the formatted volume (the physical device storage capacity subtracting the EFI partition map and other overhead) and Available shows the Capacity minus the OS and other content stored. So a reduction in OS or cache files wouldn't affect Capacity (which was about half of the total gains we saw upon upgrading).
Also: iOS and macOS present volume capacity in different terms that are (of course) equal. iOS uses binary (base 2, 1024) and macOS uses decimal (1000).
So in iOS, 1GB refers to ~1.074 billion bytes, meaning a "32GB" device is reported as having about 28GB.
In macOS, the same 32GB volume would be listed as 32GB because it counts 1GB as 1 billion bytes.
You can count to 16 in different base systems using different numbers but it's still the same 16 things:
The "apparent size" of the figures used doesn't change the actual number it represents.
I sincerely appreciate your efforts (and Sole's) to help me grasp these differences. Sadly, what little mathematical education I paid any attention to was a number of years ago perhaps too large to be expressed in any of the four notations you refer to, but I can express my technical expertise in hands, thusly: ✊ (hope that worked). Anyway, if I'm still at all possessed of logical capability, your comparison of the presentation in iOS vs. macOS, should lead to the numbers being larger in macOS (per 32GB in macOS showing as 28GB in iOS), but for me, the opposite is true. My iPhone displays 252.15GB capacity, 146.64GB available, but plugged in, iTunes reports a capacity of 238.41GB with 138.33GB 'free'.
In any case, I was never suggesting we weren't talking about the "same 16 things", or at least, I didn't mean to imply that. Only that the reporting is perhaps askew, post update (I keep thinking of Apple's struggles with clock accuracies pre- online updates, or the vagaries it sometimes shows reporting progress times remaining in updates...and no I'm not suggesting a correlation, simply that things don't always work as accurately as planned.) But thanks again for addressing it!
To the author, this has nothing to do with the size of the OS, which is probably larger. it is likely because the phone underwent cleaning of caches, logs etc.
That would explain the increase in "available", but maybe not the increase in "capacity" as noted in the illustration. I've always thought that "capacity" being less than the 256GB advertised reflected the OS size...if so, the OS is smaller now...? But I'm sure Soli will counter with that explanation about...whatever that is he's been trying to explain (to me, among others) for years!
Or, it could be that the "gains" are illusory - when I plug-in my iPhone to my MBAir to do a backup, the 'capacity' and the 'available' readings shown are very different from those on the phone itself. Maybe iOS10.3 just doesn't count very well.
I believe Capacity refers to the formatted volume (the physical device storage capacity subtracting the EFI partition map and other overhead) and Available shows the Capacity minus the OS and other content stored. So a reduction in OS or cache files wouldn't affect Capacity (which was about half of the total gains we saw upon upgrading).
Also: iOS and macOS present volume capacity in different terms that are (of course) equal. iOS uses binary (base 2, 1024) and macOS uses decimal (1000).
So in iOS, 1GB refers to ~1.074 billion bytes, meaning a "32GB" device is reported as having about 28GB.
In macOS, the same 32GB volume would be listed as 32GB because it counts 1GB as 1 billion bytes.
You can count to 16 in different base systems using different numbers but it's still the same 16 things:
The "apparent size" of the figures used doesn't change the actual number it represents.
My iPhone displays 252.15GB capacity, 146.64GB available, but plugged in, iTunes reports a capacity of 238.41GB with 138.33GB 'free'.
1) I think iTunes may use the "1024 = kilo" notation. Disk Utility used to make it clear by showing the GiB (as GB) next to actual byte count in billions but now it's a lot simpler. You have to choose your drive and select Get Info to show the number of bytes.
2) As Daniel notes, Apple lists in the footnotes of all their devices with storage:"1GB = 1 billion bytes and 1TB = 1 trillion bytes; actual formatted capacity less." That's probably the easily thing to look at. Where it becomes confusing is when that exact same notion is used as a binary prefix. Polysemes are confusing enough in language, but when it's applied to a numerical value it's even worse.
3) Let's try smaller numbers. You know that kilo comes from the Greek and means 'thousand.' That's how the notations started a long time ago. Then binary came along and 1111 1111 in binary equaled 1024 (2^8). That's so close to thousand that the notation was borrowed, and one time it wasn't off by much, but since that extra 24 gets added to every kilo in binary it really starts to add up and great a huge disparity. when you go from thousands to millions (MB) to billions (GB) to trillions (TB). When you get to 1 terabyte you're drive is nearly 10% less than you might assume because 1 trillion bytes (1,000,000,000,000) only looks like "0.909 TB" because of the notion.
4) To put another way, say that a yard and a meter both used the same naming convention. You're only off by a little over 3 inches, so if you're doing something rough, like guessing the gait of your step, you could use the same word for both and it's not a big deal. So let's call this single notion "leg length." But now try scaling that up to figure out the distance between LA and NY. How many "leg lengths" would that be when you use 36" and how many when you use 39.37"?
edit: I just did the math for LA to NY. The yard gait measurement would be 4,297,420 steps, and the meter gait measurement would be 3,944,000 steps, which would be a difference of 646,580 steps, which would result in gait-gate.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
It's more common on RAM. Reboot, folks!
One additional thing for rabid "bit-rottweilers" to consider: If bit-rot was such a perversive issue with modern SSDs, and Apple is the largest consumer of NAND, which they use in every device with an OS X variant, then why did they not consider addressing this widespread issue in their new file system?
My guess? The same reason the original Macintosh File System in 1984 wasn't hierarchical; there wasn't time. Apple has a "done is better than perfect" approach, and it's not uncommon for version 1.0 of something not to have all the features you want. I'm still holding out hope that APFS 2.0 will be checksummed.
Regardless of all that, this is still a huge, huge step forward, with or without checksums.
Some commentators [1] on other sites are saying that the new Filesystem can't cope with BitRot which happens with Solid State devices. It has been many decades since I was involved with the innards of filesystems so it would be nice to know if this is a real issue or not. Has it gone away with modern hardware?
[1] ZFS diehards mainly.
So-called bit-rot is no more common on SSDs than it is on spinning platters. Corruption happens, sure, but nowhere near as often as the ZFS diehards think it does.
It's more common on RAM. Reboot, folks!
One additional thing for rabid "bit-rottweilers" to consider: If bit-rot was such a perversive issue with modern SSDs, and Apple is the largest consumer of NAND, which they use in every device with an OS X variant, then why did they not consider addressing this widespread issue in their new file system?
My guess? The same reason the original Macintosh File System in 1984 wasn't hierarchical; there wasn't time. Apple has a "done is better than perfect" approach, and it's not uncommon for version 1.0 of something not to have all the features you want. I'm still holding out hope that APFS 2.0 will be checksummed.
Regardless of all that, this is still a huge, huge step forward, with or without checksums.
I don't know enough about filesystems to know whether that's a requirements, but I have read that they started working on APFS two years before they announced it at last year's WWDC, and I know from a long history of studying computer networking that many features in the lower levels of the networking stack are deprecated because it's more efficient or redundant when done in the higher levels. Of course, the opposite can be true in networking and lower level checks can be less resource heavy, so take my comment as its intended, and not as an implication that checksums of file data—not just the metadata—isn't necessary.
Comments
it is likely because the phone underwent cleaning of caches, logs etc.
Try this, take a phone which is almost full, try to rent a large movie in iTunes, voila more space, like magic.
If so, we could see massive Apple servers -- if only for Apple internal use... And they could run on ARM CPUs, too.
as noted in the illustration. I've always thought that "capacity" being less than the 256GB
advertised reflected the OS size...if so, the OS is smaller now...?
But I'm sure Soli will counter with that explanation about...whatever that is he's been
trying to explain (to me, among others) for years!
Or, it could be that the "gains" are illusory - when I plug-in my iPhone to my MBAir to do
a backup, the 'capacity' and the 'available' readings shown are very different from those on the phone itself.
Maybe iOS10.3 just doesn't count very well.
Yeah, wasn't improvement of SSD endurance one of the reasons Apple acquired Anobit:
https://techcrunch.com/2012/01/11/why-apple-bought-anobit/
https://arstechnica.co.uk/apple/2016/06/apple-apfs-analysis-good-and-bad-bits/3/#h4
2) As of June 2016, APFS did have checksums, but it ensures metadata integrity, not user data.
3) Regardless of whether one thinks ZFS is better than APFS or not is irrelevant since no version of OS X supports ZFS. All that matters is whether APFS is better than HFS+.
AFICT, APFS does not currently support checksums on user data to allow backward compatibility with HFS+. It also allowed iDevices to upgrade from HFS+ to APFS by leaving the user data in place and only adding new APFS metadata -- a big advantage with the limited storage on iDevices.
I suspect that a future APFS release will implement these checksums and allow the user to implement it with a download-convert-upload process.
Also: iOS and macOS present volume capacity in different terms that are (of course) equal. iOS uses binary (base 2, 1024) and macOS uses decimal (1000).
So in iOS, 1GB refers to ~1.074 billion bytes, meaning a "32GB" device is reported as having about 28GB.
In macOS, the same 32GB volume would be listed as 32GB because it counts 1GB as 1 billion bytes.
You can count to 16 in different base systems using different numbers but it's still the same 16 things:
decimal = 16
binary = 1111
hex = 0F
hands = ✋️✋️✋️☝️
The "apparent size" of the figures used doesn't change the actual number it represents.
a number of years ago perhaps too large to be expressed in any of the four notations you refer to,
but I can express my technical expertise in hands, thusly: ✊ (hope that worked).
Anyway, if I'm still at all possessed of logical capability, your comparison of the presentation in iOS vs. macOS, should lead to the numbers being larger
in macOS (per 32GB in macOS showing as 28GB in iOS), but for me, the opposite is true.
My iPhone displays 252.15GB capacity, 146.64GB available, but plugged in, iTunes reports a capacity of 238.41GB with 138.33GB 'free'.
Only that the reporting is perhaps askew, post update
(I keep thinking of Apple's struggles with clock accuracies pre- online updates, or the vagaries it sometimes shows reporting
progress times remaining in updates...and no I'm not suggesting a correlation, simply that things don't always work as accurately as planned.)
But thanks again for addressing it!
2) As Daniel notes, Apple lists in the footnotes of all their devices with storage:"1GB = 1 billion bytes and 1TB = 1 trillion bytes; actual formatted capacity less." That's probably the easily thing to look at. Where it becomes confusing is when that exact same notion is used as a binary prefix. Polysemes are confusing enough in language, but when it's applied to a numerical value it's even worse.
3) Let's try smaller numbers. You know that kilo comes from the Greek and means 'thousand.' That's how the notations started a long time ago. Then binary came along and 1111 1111 in binary equaled 1024 (2^8). That's so close to thousand that the notation was borrowed, and one time it wasn't off by much, but since that extra 24 gets added to every kilo in binary it really starts to add up and great a huge disparity. when you go from thousands to millions (MB) to billions (GB) to trillions (TB). When you get to 1 terabyte you're drive is nearly 10% less than you might assume because 1 trillion bytes (1,000,000,000,000) only looks like "0.909 TB" because of the notion.
4) To put another way, say that a yard and a meter both used the same naming convention. You're only off by a little over 3 inches, so if you're doing something rough, like guessing the gait of your step, you could use the same word for both and it's not a big deal. So let's call this single notion "leg length." But now try scaling that up to figure out the distance between LA and NY. How many "leg lengths" would that be when you use 36" and how many when you use 39.37"?
edit: I just did the math for LA to NY. The yard gait measurement would be 4,297,420 steps, and the meter gait measurement would be 3,944,000 steps, which would be a difference of 646,580 steps, which would result in gait-gate.
Regardless of all that, this is still a huge, huge step forward, with or without checksums.