[binarycrusader]

  If you think OSTree needs filesystem snapshot support, you
  aren't understanding how it works. Or perhaps we don't
  have a shared definition of "robust" - for me, assuming
  correct behaviour at the filesystem and block layer, I
  believe deployment changes to be atomic.

I'll put this differently; how can OSTree reliably get a system from StateSRC -> StateDEST without filesystem-level snapshots?

If the answer is that an administrator must define what StateSRC is every time they upgrade their system, I don't think that's a usable mechanism.

If it does it based on the live system (the best answer), then without filesystem-level snapshots, how can OSTree reliably define StateSRC? There's a non-trivial set of race conditions OSTree would encounter while attempting to create its own "snapshot" of the state of the system.

Having filesystem-level snapshots allows you to get an accurate view of the live state of the system so that you can then modify a copy.

With ZFS, snapshots are basically "zero cost". Or rather, they have very low overhead for the base snapshot, and you only incur additional expense from divergences in the snapshot from its parent.

[colinwalters]

> I'll put this differently; how can OSTree reliably get a system from StateSRC -> StateDEST without filesystem-level snapshots?

Your comment strongly implies to me you don't understand how it works. It's really really simple - the physical / of the filesystem no longer stores the OS. Instead, you have multiple chroots in /ostree/deploy/osname/{checksum1, checksum2} etc.

To make a new checkout, it's just a hardlink farm.

This kind of thing has been done to some degree before - it's not entirely new. OSTree just polishes it, makes it more efficient, documents the semantics of /var, etc.

[binarycrusader]

You're right that I don't fully understand how it works, which is why I was asking; there's no summary of how it works on the main page and I don't have the time to read the source code or attempt to digest the entire manual.

How do you define the initial chroot? Who is responsible for creating that?

How would you migrate an existing system to use OSTree?

If an administrator has to manually create the initial chroot link farm, I don't think that's a very usable solution. In particular, it suggests a lot of process overhead that assumes most systems are "templatable" representations.

It's not immediately clear whether OSTree deals with necessary in-place upgrades or if it only helps you with reboot-based ones.

Even if you don't feel in-place upgrades are safe, again, most enterprise-level customers are demanding update solutions that don't require them. There's a reason why ksplice, et al. are becoming popular.