Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple File System

developer.apple.com

Post reply on HN
Print view View original

341–350 of 406 posts

Re: Apple File System

#341

Post by bemmu »

laumars wrote: post #325
Twisell wrote: post #306

Earlier quoted context omitted.

18 years ago, while being a teenager, I misconfigured CCC only to find out that only the active user folders where synced after a full erase/reinstall upgrade of MacOS. This was my epic "there is to kind of people those who lost data and those who will loose data" story. All my dad and mum files where gone, luckily nothing professional and no pictures (analog camera still ruled back then). This is just a reminder tha…

I appreciate this was a long time ago and you've learned a lot since, but your story perfectly illustrates the importance of not just performing backups, but periodically testing them as well. That way you eliminate your blind faith in a black box by ensuring you actually have a working solution to fallback on.

I keep hearing this, but as a Mac user who uses Time Machine and CCC, what's a good way to test the backups? After all deleting my only system to attempt a restore seems even more dangerous.

Re: Apple File System

#342

Post by lake99 »

majewsky wrote: post #141
cuddlybacon wrote: post #84

Earlier quoted context omitted.

Steam relies on the filesystem being insensitive.

No it doesn't. How would it work on Linux if it did?

Both, you and cuddlybacon are right. A long time ago, they worked under the assumption that the FS is case-sensitive, and all the games I installed back then had title-cased folder names. Gradually, Valve stopped caring about this, and my games stopped working. I had to go in and manually change some game folder names to lower-case. It then kept some small files under SteamApps and the downloaded games under steamapps. They have fixed that now. Now, I have both CONFIG and config in my Steam folder.

How would it work? By a combination of magic and "we can't be bothered; the users should figure out something".

Re: Apple File System

#343

Post by zyx321 »

ysleepy wrote: post #192
derefr wrote: post #121

Earlier quoted context omitted.

The point of encrypting the base system image is mostly to make it part of the Secure Boot chain. rootless is a policy control to stop processes from modifying the OS from inside. An encrypted system image stops things with hardware access (but not the unlock key) from modifying the OS from the outside . You can trust any disk whose blocks you can decrypt with key X, to have been only written to by someone with key X…

thanks for mansplaining rootless and encryption (/s). Encryption is not authentication, so it does not prevent unnoticed modification. And secure boot only really depends on authentication and not on encryption, so you are conflating two different concepts. No you cant just trust the data, replay attacks over time and space are still an issue.

>mansplaining

Thank you for injecting sexism into a technical discussion.

Re: Apple File System

#344

Post by mpweiher »

dang wrote: post #98
DannyB2 wrote: post #68

Complain if you want, but you seem to forget that it is from Apple. And that makes it somehow better with magical goodness that nobody else could attain. Apple's engineers are not mere humans like every other 'ordinary' tech company would hire. /s

Please don't. Comments like this make the discussion quite a bit worse in their own right. We detached this subthread from https://news.ycombinator.com/item?id=11897039 and marked it off-topic.

Former Apple engineer here. Yes, it sounds snide on the surface, but there is a lot of truth to it. I actually remember those of us on the inside being rather a- and bemused by the "magic" qualities we and our output had suddenly acquired.

Re: Apple File System

#345

Post by mkup »

danudey wrote: post #316
ryao wrote: post #217

Earlier quoted context omitted.

ZFS data deduplication does not require much more ram than the non-deduplicated case. Performance will depend heavily on IOPS when the DDT entries are not in cache, but the system will run slowly even with miniscule RAM.

In my experience, ZFS will choke out the rest of the system RAM, and swap like crazy, killing the system.

If dedup is off, and max ARC size is limited, it will use a little memory (e.g. 512 Mb of RAM for 2x2TB RAID1 pool). I can say that from my own experience, I tried both approaches.

Re: Apple File System

#346

Post by zyx321 »

ahl wrote: post #161

The spartan description of APFS certainly sounds like the (partial) feature list for ZFS--the comparisons made in the comments here are on-point. ZFS though took around 5 years to ship and, arguably, another 5-10 to get right. I say this having shipped multiple products based on ZFS, writing code in ZFS, and diagnosing production problems with it. On-disk consistency ("crash protection"), snapshots, encryption, and t…

It's good to see Apple catching up, no matter where it's coming from. You mention ZFS, but per-file encryption (EFS) and snapshots (VSS) in particular stood out to me as features NTFS has had for a decade.

Re: Apple File System

#347

Post by paride5745 »

rleigh wrote: post #200

While I am happy that Apple have at last committed to replacing HFS+, I'm wondering why they didn't use ZFS rather than reinventing the wheel. It's not like it's a particularly easy wheel to reinvent either; the amount of effort which goes into a filesystem like ZFS is non-trivial. Why not build on top of that? I would have greatly appreciated being able to use ZFS with MacOS X, for datasets, snapshots, sending them…

Apple should have bought Sun at the time, and cross-pollinate Mac OS X and Solaris while using OpenSolaris to attack the server/cloud market.

Re: Apple File System

#348

Post by Chyzwar »

Arrogance... Instead using ZFS they build new file system from scratch (APFS) Instead using Vulkan they build new Graphics API from scratch (Metal)

Keep this up and they will end like MS.

Re: Apple File System

#349

Post by chucknelson »

Chyzwar wrote: post #348

Arrogance... Instead using ZFS they build new file system from scratch (APFS) Instead using Vulkan they build new Graphics API from scratch (Metal) Keep this up and they will end like MS.

I'd be more interested in understanding why they chose to implement their own file system instead of adopting something like ZFS.

No doubt there is reasoning in there besides the "we are an evil company" logic - Apple developers are people too...

Re: Apple File System

#350

Post by ryao »

kstrauser wrote: post #150
ryao wrote: post #128

Earlier quoted context omitted.

ZFS needs very little memory to run. Performance is definitely better with more RAM, but the overwhelming use of memory in ZFS is for cache. Eviction is not particularly efficient due to the cache being allocated from the SLAB allocator, but that is changing later this year. Getting ZFS to run on the Apple Watch is definitely possible. I am not sure what acceptably means here. It is an ambiguous term.

The FreeBSD wiki ( https://wiki.freebsd.org/ZFSTuningGuide ) still claims: > To use ZFS, at least 1 GB of memory is recommended (for all architectures) but more is helpful as ZFS needs lots of memory. Is that inaccurate?

The wiki page should be corrected. Saying "lots of memory" is somewhat ambiguous. If this were the 90s, then it would be right.

As for the recommended amount of system memory, recommended amounts are not the minimum amount which code requires to run. It in no way contradicts my point that the code itself does not need so much RAM to operate. However, it will perform better with more until your entire working set is in cache. At that point, more RAM offers no benefit. It is the same with any filesystem.

Post reply on HN