Frank Middleton wrote:
The confusion seems to be what setting the image property
flush-content-on-success appears=true is supposed to do
and when it does it. It doesn't seem to do anything, and I am
trying to understand why.
On 10/ 7/09 02:36 AM, Shawn Walker wrote:
Frank Middleton wrote:
No idea what was in /var/pkg/download before rebooting; it was not
empty afterwards.
Ah, okay then. That's expected behaviour (currently).
But it was empty before starting the image-update, so the contents
are related to the new BE, not the old one. From what you said, is it
true that the emptying process doesn't happen until after a reboot?
No. Let me try to explain again, as far as I have observed/understand
the process, this is (roughly) what happens if you have
flush-content-on-success set to True:
$ pkg image-update
* pkg creates an update plan
* pkg downloads everything needed for update
* pkg executes plan
* plan execution creates a new boot environment and mounts it
* plan execution performs the update on the new boot environment
* plan execution finishes, purging the contents of /var/pkg/download
_only_ for the new boot environment
* pkg client exits, as the operation is finished
So what this means is that the /var/pkg/download directory in the new
boot environment should be purged if you've set flush-content-on-success
True. However, it will *not* purge /var/pkg/download in the active boot
environment (the one that is active before you reboot).
My guess is that this was intentional to allow you to perform
image-update again without having to re-download the content.
quietly. How does this process get scheduled? If my understanding
is incorrect, then does pkg report the install as complete even
though it is still trying to empty the cache? If this is the case,
No.
With that said, feel free to file a bug asking for
flush-content-on-success to affect the original boot environment and
not just the new one.
IIRC by default, there's a snapshot around the original BE. It would
be impossible to free up any space in the original BE without deleting
the snapshot first, so I suspect anything that would affect the
original BE might be hard to do. Since emptying /var/pkg/download
before or after is trivially easy to do manually, it really doesn't seem
worth pursuing, especially since I understand this is currently an
unsupported feature. Being able to image-update in 16GB is probably
much more important since there may be quite a few folks with 16GB
boot SSDs (or even disks) and I believe it is currently impossible to
go from b124 to b125in much less than 20GB.
As I said, there are plans to either move /var/pkg/download somewhere
else or make it part of a separate dataset, since, as you pointed out,
destroying a specific dataset is faster than trying to delete 2GB of
individual files.
Cheers,
--
Shawn Walker
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
