Apfs Firmware Update

JF Mezei wrote:
> With a totally new way to update files being used for APFS with
> snapshots etc, does this mean that a system update/upgrade could be done
> on a running system with a new version of files being created while the
> running system still has files opened pointing to the old version?

I think you need to go away and read/view the APFS presentation at last
year's WWDC again. It would also help if you stop obsessing about APFS
being some magic that will completely change the way things work.
New features of APFS have little to do with software updates.
The only way snapshots figure in software updates would be to save the
state of the file system so an update can be rolled back if something
goes wrong while it is being installed, or if the user decides they
don't like the result and want to revert to the prior state, or to allow
mounting the prior state (read only) for comparison.
Clones might help updates by reducing the amount of data needing to be
copied when a file is patched (assuming the patch is replacing a block
of data the same size, which is probably rare).

> (with old versions then deleted at reboot since the system would then
> boot with most recent version of files) ?

Unix file systems (including HFS+) can already do that.
The problem with OS updates is nothing to do with how files are
replaced, but with coordinating all parts of the system to use the same
versions of a related set of files. The easiest way to ensure that is to
restart.

> In a different vein, if file1 is some indexed database file, and
> process1 updates records in it while process2 accesses records, will
> process2 continue to access its 'snapshot' of the file at the time it
> opened it, or would it get updated records (written in different blocks) ?

Existing databases can already do that without file system help, e.g.
SQLite in WAL mode: if reader A starts a transaction, then writer B
starts a transaction, makes changes and commits, reader A continues to
see the old state of the database until its transaction ends. The
changes are visible to reader A when it starts its next transaction.
The clone feature in APFS is somewhat similar but would require the
database software to close and reopen the database to see changes done
in a clone which then replaced the original file.
This would certainly be faster, as it avoids double writing new/updated
database pages (initially to the WAL file, then later to the main
database at a checkpoint).
Supporting this would require a new journalling method and updated
database software, but old journalling methods would still need to be
supported for other file systems, therefore it increases the complexity
of cross platform database engines for a feature only available on a
limited number of systems. That makes it less likely to be supported by
cross-platform database engines like SQLite, unless Apple did a
platform-specific branch.

> Or put it another way, would an application specify, when it opens a
> file, whether it wants a static snapshot at time of opening versus
> dynamic accxess to the file as it is being modified by others ?

Snapshots have nothing to do with opening files. They are for saving the
state of entire volumes.
--
David Empson
dem..@actrix.gen.nz