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

401–406 of 406 posts

Re: Apple File System

#401

Post by tedmiston »

newscracker wrote: post #400
tedmiston wrote: post #372

Earlier quoted context omitted.

Of course you can see the full list at /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist. One of the biggest is iPhone backups from iTunes. If I were a normal user and my MacBook didn't boot up tomorrow, I'd be surprised to find my backup didn't include critical files like this. For example, apps that are no longer in the App Store but are in your backup can be restored. Once you don'…

I'm not sure why the iPhone backups on your system didn't get backed up. The device backups stored in ~/Library/Application Support/MobileSync/Backup/ is not in the exclusions file that I see. P.S.: The latest app binary files may not get updated/synced on the Mac post iOS 9/iTunes upgrade.

I double checked my drive and you're correct with regard to mobile backups. That's reassuring.

It would be nice to have a utility to give a definitive diff of what's on your hard drive that's not on your: Time Machine drive / [Carbonite, Backblaze, etc] backup.

Re: Apple File System

#402

Post by rzhikharevich »

rdsnsca wrote: post #386
0x0 wrote: post #229

Hopefully 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! :)

Doubt that. .DS_Store are created by the Finder.... not the file system.

As of the first macOS Sierra developer beta version there are no .DS_Store files on APFS volumes.

Re: Apple File System

#403

Post by raattgift »

ryao wrote: post #397
wstrange wrote: post #247

Earlier quoted context omitted.

But why couldn't ZFS also take advantage of those opcodes?

It is platform dependent. ZFS does not do that on Linux yet in part because of GPL symbol restrictions and the fact that there are other things to develop right now, although there has been some work done in this area to use the instructions directly. It definitely takes advantage of them on Illumos. I am not sure about the other platforms.

xnu's loadable kext isolation means that you have a one-time hit on using anything beyond x86-64+sse2, which can be paid at kernel prelink time, kext load time, or while a kext is running, via a trap that switches call preamble/postamble to handle the extra state (and which facilitates selecting fast paths on a cpu-by-cpu basis, for example). Only the presence of x87 insns impose noticeable cost.

o3x builds and runs just fine with -O2 -march=native and the latest clang just by changing CC and CFLAGS; the kexts that get built aren't backwards compatible though (you'll get a panic if you build with -march=native on a machine that does AVX and run on a machine that doesn't).

The code that recent clang+llvm generates makes heavy use of the XMM and YMM registers, and does some substantial vectorization. The compression and checksumming and galois field code that's generated is strikingly better, although not quite as good as the hand tuned code in e.g. (https://github.com/zfsonlinux/zfs/pull/4439). It may be interesting to compare performance, but given that compression=lz4 and checksum=edonr has negligible CPU impact on a late 2012 4-core mac mini (core i7) even when doing enormous I/O (> 200k IOPS to a pair of Samsung 850 PROs), hand tuning likely won't make as much of a difference as moving up from compression=on, checksum=[sha256|fletcher4].

I'm pretty sure that once the hand tuned stuff is in ZOL it'll get looked at by lundman for possible integration.

Re: Apple File System

#404

Post by raattgift »

ryao wrote: post #352
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.

I probably should clarify that the system could definitely run unacceptably slow when deduplication is used and memory is not sufficient for the DDT to be cached. My point is that saying ram is needed is saying that the software will not run at all, which is not true here.

Or when the cache is cold. It REALLY hurts to reboot while a deferred destroy on a big deduplicated snapshot is in progress. No import today for you!

Well, unless your medium has no seek penalty, which is what hurts with deduplication. Dedup on SSDs is pretty much OK, as long as your checksum performs reasonably (skein is reasonable; sha256 is not).

DDTs that fit inside no-seek-penalty L2s don't hurt that much either, and big DDTs on spinny-disk pools are acceptable with persistent l2arc, although it's risky because if the l2 fails, especially at import, you can have a big highly deduplicated pool that isn't technically broken but is fundamentally useless if not outright harmful to the system it's imported (or ESPECIALLY attempting to be imported) by. "No returns from zpool(1) or zfs(1) commands for you today!"

When eventually openzfs can pin datasets and DDTs to specific vdevs (notably ones made out of no-seek-penalty devices), heavy deduplication on big spinny disk pools should be usable and reliable.

Until then, "well technically even if you have only ARC and it's very small, it will work, just slowly" while correct in the normal case, is unfortunately hiding some of the most frustrating downsides when things go wrong.

Re: Apple File System

#405

Post by Chyzwar »

taharvey wrote: post #391
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.

ummmm... metal cames out 2 years before vulkan. Vulkan was inspired by metal.

nope, both are inspired by AMD Mantle.

Apple not only ignored first major consensus in Games industry it also blocked support on its devices. It also stuck with old OpenGL. This will make gaming on Apple to suck for many years to come.

Re: Apple File System

#406

Post by Chyzwar »

chucknelson wrote: post #349
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...

I just do not understand rationale. File systems is hard stuff, instead taking something that is probably best file system around they decided for long and painful road. Note that they worked before on OpenZFS in Apple ....
Post reply on HN