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

351–360 of 406 posts

Re: Apple File System

#351

Post by ryao »

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.

Kernel memory on the platforms where ZFS runs is not subject to swap, so something else happened on that system. The code itself is currently somewhat bad at freeing memory efficiently due to the use of SLAB allocation. A single long lived object in each slab will keep it from being freed. That will change later this year with the ABD work that will switch ZFS from slab-based buffers to lists of pages.

Re: Apple File System

#352

Post by ryao »

ryao wrote: post #217
watersb wrote: post #199

Earlier quoted context omitted.

ZFS de-duplication will eat all of the RAM you can throw at it. Otherwise, it is basically the SLUB memory block allocator that was used in the Linux kernel for a while. So yes, it can run on watchOS-level amount of RAM.

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.

Re: Apple File System

#353

Post by zeckalpha »

msbarnett wrote: post #246
drinchev wrote: post #58

Earlier quoted context omitted.

Still... Marketing fully-encrypted snapshot-featured filesystem with focus on SSD / Flash, would make much more impact than having "native-tabs" for apps on an event like that. Anyway I'm not a specialist, just another IT guy, so maybe I'm too opinionated to argue more.

The press understands "apps" and "tabs". The press doesn't understand "filesystem snapshots". Part of the reason Apple has historically gotten much better press from WWDC than most tech companies do from their big developer events is that they laser-focused their keynote on being Press-digestible and not full of incomprehensible tech terminology that bores non-geeks to tears. As evidenced by this thread, the people "…

> The press understands "apps" and "tabs". The press doesn't understand "filesystem snapshots".

That's a limited view of the press.

Re: Apple File System

#354

Post by nullymcnull »

lai wrote: post #184

Oh I forgot, you can't read Apple documentation on a mobile chrome browser.

Even on Chrome desktop, if you turn on Mobile emulation and switch it to appear to be any Android device w/ phone display size, it fails in the same way - yet switch it to 'iPhone 5' or 'iPhone 6' and the same compact layout works fine. They're pointlessly sniffing and special-casing 'Android' user-agents and botching it completely.

Re: Apple File System

#355

Post by Freaky »

derefr wrote: post #264
ysleepy wrote: post #192

Earlier quoted context omitted.

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.

I'm not the one conflating them; it's the Secure Boot people who think this is a good idea. Full-Disk Encryption is the defined "OS" stage of the Secure Boot chain-of-trust today, acting as an "optimization" (heh) over signing disk blocks. It's certainly more secure (indeed, it prevents replay attacks) to just keep a big block-hash table, update it when blocks change, and then hash that table and sign it on fsync—but…

> Do any block-device cryptosystems support an AEAD mode yet?

FreeBSD's geli supports authenticating data with HMACs.

https://www.freebsd.org/cgi/man.cgi?geli(8)#end

Re: Apple File System

#356

Post by rbanffy »

0942v8653 wrote: post #63
rbanffy wrote: post #53

Earlier quoted context omitted.

Copy-on-write and snapshots are excellent building blocks for Time Machine, so much in fact that, when it was announced, I suspected it was because of ZFS (which, at the time, was being considered for OSX). It's very likely TM will be adapted to work on it (with about 20 lines of code)

I'm not sure about snapshots, TM is made to work by just copying the directory structure over, and each backup is a fully functioning hierarchy. But cloning is definitely a big deal.

A snapshot is a copy of the file (and its blocks) at a given point in time. Subsequent writes to it will happen to new blocks, leaving the ones connected to the snapshot undisturbed.

Re: Apple File System

#357

Post by _pmf_ »

speleding wrote: post #89
entee wrote: post #60

Earlier quoted context omitted.

Presumably as with today, you'll have the option. I don't have a strong opinion on case sensitivity of file names, but I suspect they'll keep it case insensitive by default. I think for the average non-technical user that two files, "MyFile.txt" and "myfile.txt", being different could lead to some confusion, and Apple historically has apparently considered that confusion unacceptable.

For the end-user they could prevent duplicate different-cased file names in the UI layer (the Finder), instead of the file system. That would be a more appropriate place for it anyway.

This is a horrible solution.
Post reply on HN