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

241–250 of 406 posts

Re: Apple File System

#241

Post by tedmiston »

PhantomGremlin wrote: post #235
karlshea wrote: post #97

Earlier quoted context omitted.

> > Snapshots > If those can be sent: Finally Time Machine done right. If this ends up being true I can't wait—it's so frustrating watching tiny incremental backups take forever over the network. It seems like "Preparing" and "Cleaning up" take longer than moving the data.

it's so frustrating watching tiny incremental backups take forever over the network While waiting for APFS to become stable, buy Carbon Copy Cloner. $40. I love it. It's fundamentally rsync, but tailored to OS X. For personal use a single license covers an entire household. Every night CCC fires up on each laptop and each does an incremental clone to its own dedicated directory on my desktop machine. This clone is us…

CCC was what I used back in the day (IIRC it used to be free) to make the most reliable bit-for-bit backups of OS X machines. Time Machine skipping over so many files is kind of a nuisance to me.

Re: Apple File System

#242

Post by astrange »

hyperpape wrote: post #80
amock wrote: post #55

Earlier quoted context omitted.

That's not really a useful statement. HFS+ has worked pretty well for many years and is really well tested. This will be a completely new filesystem, which means it will have lots of new code that can have bugs or incompatibilities with current apps. APFS sounds like it's going to be great, but I think not being HFS is a disadvantage rather than an advantage.

It's tested, so there's less risk of new and unexpected bugs, but the known problems are significant: https://blog.barthe.ph/2014/06/10/hfs-plus-bit-rot/ .

HFS+ didn't lose any files, his hard drive did. He wouldn't necessarily be able to get them back with filesystem-level checksum either, but he would know they're gone faster.

BTW, disk images already provide checksumming, and so does authenticated encryption.

Re: Apple File System

#243

Post by Jerry2 »

Bytes wrote: post #148

This is a huge feature. I have no idea why Apple didn't include this in their keynote.

It was featured in Platforms State of the Union... which is the "real" keynote targeted at developers.

You will be able to see it here shortly:

https://developer.apple.com/videos/play/wwdc2016/102/

Re: Apple File System

#244

Post by msbarnett »

1amzave wrote: post #152
imglorp wrote: post #46

Earlier 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.

There's plenty of code in the wild that assumes case-insensitivity since that's been the case since forever.

Backwards compatibility is going to end up trumping whatever ideological purity case sensitivity represents.

Re: Apple File System

#245

Post by peckrob »

PhantomGremlin wrote: post #235
karlshea wrote: post #97

Earlier quoted context omitted.

> > Snapshots > If those can be sent: Finally Time Machine done right. If this ends up being true I can't wait—it's so frustrating watching tiny incremental backups take forever over the network. It seems like "Preparing" and "Cleaning up" take longer than moving the data.

it's so frustrating watching tiny incremental backups take forever over the network While waiting for APFS to become stable, buy Carbon Copy Cloner. $40. I love it. It's fundamentally rsync, but tailored to OS X. For personal use a single license covers an entire household. Every night CCC fires up on each laptop and each does an incremental clone to its own dedicated directory on my desktop machine. This clone is us…

I've migrated many Macs using Carbon Copy Cloner. Works fabulously and is a great tool.

Re: Apple File System

#246

Post by msbarnett »

drinchev wrote: post #58
waterphone wrote: post #35

Earlier quoted context omitted.

The keynote was for consumers and the press. The 2 PM PT Platforms State of the Union is for developers and will likely go into this more, and if not there is a session tomorrow specifically about it.

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 "filesystem snapshots" can be marketed to didn't need it to be mentioned in the keynote to get them talking about it. Hence, using precious keynote time for it would have been a waste of marketing resources.

Re: Apple File System

#247

Post by wstrange »

mschuster91 wrote: post #156
ryao wrote: post #133

Earlier quoted context omitted.

ZFS will be happy on a system with only 512MB of RAM, no matter how much storage it manages (assuming only 1 pool). It does need more RAM than UFS, but the amount is not notable unless we are talking about systems with 32MB of RAM. Being energy hungry relative to UFS and others is likely true due to things like checksum calculations and compression, but there is no way to implement these things without needing more c…

> Being energy hungry relative to UFS and others is likely true due to things like checksum calculations and compression, but there is no way to implement these things without needing more cycles to compute them. Not so true now - people have added encryption and compression instructions to CPUs. I'd be surprised if Apple couldn't ask Intel for a couple opcodes, and with the mobile platforms they do it anyway.

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

Re: Apple File System

#248

Post by wstrange »

wcummings wrote: post #207
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…

How does AAPL feel about the CDDL?

Given that there are other companies shipping ZFS without Oracle's blessing, I am curious why Apple could not do the same? (honest question)

Is it that Apple is a much bigger target? Patent issues?

Re: Apple File System

#249

Post by derefr »

majewsky wrote: post #146
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…

Why would you need encryption for the Secure Boot chain? Would you not rather sign the base system image for that purpose?

You'd have to sit there and read the entire base system image before booting to verify that signature. But only have to decrypt a block when it comes time to read that block—with the ability to kernel-abort right then during the boot process if the block doesn't decrypt. (Or were you suggesting individually signing every block?)

Re: Apple File System

#250

Post by wstrange »

skrause wrote: post #19

No checksumming?

I have a theory on this regarding consumer devices:

Checksumming drives a lot of support calls that would otherwise not happen. As long as the errors are in media files and not meta-data, most consumers are going to be oblivious to bit rot in their downloaded movies and photos.

Enabling checksumming is going to reveal a lot of errors that would otherwise be silently ignored (spoken from experience running a ZFS media server)

Post reply on HN