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

251–260 of 406 posts

Re: Apple File System

#251

Post by Retra »

bjt wrote: post #91
crucialfelix wrote: post #81

Earlier quoted context omitted.

More problematic is that many case insensitive hard drives would be copied into new machines and there would be millions of conflicts. Some utility would have to sit there and annoy people by asking them to make decisions.

I can see why there would be conflicts going case sensitive -> case insensitive, but I can't see why there would be conflicts going the other way. Am I missing something?

If you have a file named "MyFile.txt" and another system is looking for "myfile.txt", then it'll not be found and Apple will not let you rename it because it thinks it's a no-op. That's frustrating as hell.

Re: Apple File System

#252

Post by Retra »

skrause wrote: post #41
anc84 wrote: post #28

Earlier quoted context omitted.

Free software and patent-free or whatever some lawyers call "open"?

They said "publish the APFS volume format". So that can mean just documentation and not code at all.

Published code doesn't mean 'open' either. You need rights to the code, not merely access to it.

Re: Apple File System

#253

Post by AceJohnny2 »

ahl wrote: post #238
mioelnir wrote: post #196

Earlier quoted context omitted.

Between the ZFS-like features and the advertised "novel copy-on-write metadata" scheme, I would not be surprised if it was partially based on DragonFly's HAMMER/HAMMER2 filesystem.

It would be a strange kind of NIH that excluded ZFS but welcomed HAMMER...

Licensing.

Re: Apple File System

#255

Post by mindajar »

mioelnir wrote: post #196
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…

Between the ZFS-like features and the advertised "novel copy-on-write metadata" scheme, I would not be surprised if it was partially based on DragonFly's HAMMER/HAMMER2 filesystem.

If you poke around in the the APFS kernel extension, it's not a very big binary, given the feature set. (It's a 550K extension, compared to the 2.5MB zfs.ko on FreeBSD.) I haven't disassembled it yet, but I'd wager that APFS is layered atop Core Storage btrees/CoW. Since that code's been shipping since 2011, maybe APFS stabilizes faster than a true greenfield filesystem?

(That does leave me wondering how interesting an open-source APFS would be without an open-source Core Storage.)

Re: Apple File System

#256

Post by zrm »

0x0 wrote: post #225
zrm wrote: post #221

Earlier quoted context omitted.

Taking advantage of the differences between flash and spinning rust only requires that you know which one you're running on. Moving the wear leveling code into the OS where the filesystem can see it is an interesting idea but why aren't we doing that for all SSDs and operating systems then?

(raw) flash and spinning rust are fundamentally different, because spinning rust drives provide a READ SECTOR and WRITE SECTOR primitive, while raw flash provides READ SECTOR, ERASE (large) BLOCK, WRITE (small) SECTOR primitives. Stuff like UBIFS do try to move the wear leveling code into the OS. But the big players like Windows' NTFS and Mac's HFS were originally designed for the spinning rust primitive, so I guess…

They have their secret sauce so that legacy software can pretend the SSD is spinning rust. Let them.

Why shouldn't we also demand standard low level primitives so that every OS can do the thing you're describing?

Re: Apple File System

#257

Post by CGamesPlay »

DannyBee wrote: post #50
cpr wrote: post #2

Siracusa will finally be happy. ;-) Sounds an awful like like ZFS (zero-cost clones, read-only snapshots) but could it be? I would imagine they'd start from scratch to due IP issues. Clearly this is immature technology they want to get out for testing/evaluation before it's fully adopted even into their own products. (See below.) - - - from the release notes - - - As a developer preview of this technology, there are…

"FileVault: APFS volumes cannot currently be encrypted using FileVault. " This one is confusing, because this is a logical volume feature. Not sure how or why APFS would ever care that some layer above it is encrypting stuff.

Err, per [1]

> APFS supports encryption natively. You can choose one of the following encryption models for each volume in a container: no encryption, single-key encryption, or multi-key encryption with per-file keys for file data and a separate key for sensitive metadata. APFS encryption uses AES-XTS or AES-CBC, depending on hardware. Multi-key encryption ensures the integrity of user data even when its physical security is compromised.

[1] https://developer.apple.com/library/prerelease/content/docum...

Re: Apple File System

#259

Post by cynix »

bjt wrote: post #175
imglorp wrote: post #109

Earlier quoted context omitted.

I think you have it backwards. If you try to expand an archive with FOO.TXT and foo.txt, what should happen if you're writing to a case insensitive file system? $ touch HI $ touch hi $ ls HI So that's disturbing. Another problem is every software you can think of will be comparing two files case insensitively. Almost weekly I get burned by this. $ touch HI $ test -f hi && echo ok ok

That's not convincing me that I have it backwards. I was responding to this point in the parent comment: > many case insensitive hard drives would be copied into new machines and there would be millions of conflicts I still don't see where you get a conflict copying the contents of a case-insensitive file system to a case-sensitive one.

> I still don't see where you get a conflict copying the contents of a case-insensitive file system to a case-sensitive one.

Because some apps create MyFile.txt and expect to be able to access it later by myfile.txt. Adobe's applications, for example.

Re: Apple File System

#260

Post by rhizome »

ryao wrote: post #128
TillE wrote: post #57

Earlier quoted context omitted.

ZFS gobbles RAM and almost certainly couldn't be made to run acceptably on the Apple Watch. No, this seems like something developed from scratch to meet their particular needs.

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.

Interesting, because on Reddit's /r/DataHoarder they recommend a "1GB RAM per terabyte of storage" rule of thumb. [standard Reddit disclaimer]
Post reply on HN