[oi-dev] Weird data-loss in build zone connected to pkg update, snapshots and co

[Jim Klimov]

On 2013-06-26 15:23, Erol Zavidic wrote:
> I had my build zone up and running and started pkg update on GZ. All
> went fine, just that I waited with the reboot. I was working on
> libmemcached last night late and had some progress there.
>
> This morning I booted up by desktop (with the new image), booted build
> zone and my files are lost, filesystem was reset to state of aprox. two
> days ago.


Similar to what Alexander wrote, but in more detail: the package update
process may create a snapshot and/or clone of the BEs it changes. Each
BE has a unique GUID (as a ZFS attribute), and zone datasets reference
it so that proper zone filesystem versions are mounted along with the
root BE. I think it is so, at least - though would moderately not make
sense if you didn't pkgupdate the zone environments as well.

You continued your work in the mounted zone's dataset, but another clone
was mounted after you rebooted. Your work should not be lost, however,
and you should be able to explicitly mount and/or clone and mount the
zone's "current" state and extract those files, or take a light risk and
fix the zbe/root's attributes which link a particular clone dataset to
the "parent BE" GUID, so that your zone with working files is mounted.

Systematically, it might be better to do development and data storage
not in the BE datasets (global or local zone system datasets), but in
a separately defined and mounted datasets which are not impacted by
beadm and packaging activities. For example, it may be convenient to
lofs-mount the whole /export tree into the local zones (especially if
you are the only user of the machine and/or trust all users equally),
so that user homes are identical in all of your operating environments.

HTH,
//Jim