No checksumming?
Can you implement COW filesystems without some kind of checksumming? Or have I been in ZFS-land for too long?
Apple File System
291–300 of 406 posts
Re: Apple File System
#292Earlier quoted context omitted.
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
#293Earlier quoted context omitted.
> The AFP protocol is deprecated and cannot be used to share APFS formatted volumes. Interesting. That is really interesting. I recognised with El Capitan that it already defaults to SMB instead of AFP when you don't give a scheme.
AFP is also a security disaster. Check out the spec for "DHX2" https://developer.apple.com/library/mac/documentation/Networ...
Re: Apple File System
#294While 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…
How does AAPL feel about the CDDL?
Re: Apple File System
#295> Flash / SSD Optimization I.e., a "unique copy-on-write design" > Space Sharing Basically, ZFS datasets. > Snapshots If those can be sent: Finally Time Machine done right. > The AFP protocol is deprecated and cannot be used to share APFS formatted volumes. Interesting. > An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format when Apple File System is r…
I found forcing user to SMB weird given how crap their driver is...
Re: Apple File System
#296Re: Apple File System
#297Earlier quoted context omitted.
Will they deploy it case insensitive, still?
According to their documented "Current Limitations" ( https://developer.apple.com/library/prerelease/content/docum... ): > Case Sensitivity: Filenames are currently case-sensitive only. First thought: they have seen the light! A moment later: wait...they consider this a "limitation", and it's only "currently" the case. So maybe they're going to perpetuate the brain-damage anyway. Sigh.
Re: Apple File System
#298Hopefully this will be the end of .DS_Store and the crazy unicode normalization issue that causes mixups when rsync-roundtripping a directory structure between ext4 and HFS! :)
Let's recap:
- On OS X HFS+, filenames are stored using a "variant" of NFD, where some characters are precomposed "for compatibility with old Mac text encodings" (https://developer.apple.com/library/mac/qa/qa1173/_index.htm...).
- On Windows NTFS, filenames are "opaque sequences of WCHARs", and are thus "kind of" UTF-16 with no formally required normalization format. Windows itself tries to use NFC, but applications are free to use the Windows APIs to create a filename with anything they like. Since filenames are just sequences of 16-bit WCHARs, dangling surrogate pairs are allowed (and can break all sorts of code!)
- On Linux, filenames are opaque sequences of 8-bit characters. The only requirement is that a filename not contain either a slash or NUL character. No other formal specification exists, although "most" users these days use UTF-8. (However, you can and will find loads of filesystems with invalid UTF-8, usually because filenames are in one of the ISO encodings instead).
Multiple programming languages have been bitten by the possibility of invalid Unicode in filenames (see for example: rust (https://github.com/rust-lang/rust/issues/12056), Python (https://www.python.org/dev/peps/pep-0383/)). This mess is pretty much never going to go away, either, because filesystems are extremely durable and long-lasting.
Re: Apple File System
#299Earlier quoted context omitted.
I found forcing user to SMB weird given how crap their driver is...
Crap driver? It's not a 'driver', and smb has been natively supported for at least 8-10 years. It hasn't sucked in a looong time either. In fact recent OS versions have defaulted to smb v2 for file sharing.
Anecdotally, I'd always found AFP in the Tiger and Leopard days to be faster than whichever version of SMB support was included at the time. Now I use the default SMB3 and it seems that 802.11ac and gigabit are bottlenecks (of course its 10 years later in the times of SSD's as well)
Re: Apple File System
#300The 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…
Either way, what file system didn't take years to get right? There are so many possible edge cases with file systems that it not only takes a long time to sort them out, but an amazing community and/or luck to reproduce deterministically to fix them.