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?
Since emptying a directory of 2GB's worth of smallish files is going
to take quite a long time., what process would actually be doing the
emptying? Even though zpool iostat didn't show anything at that
moment, there could have been a stalled background job running
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,
rebooting would interrupt the emptying process which would
presumably not restart. Understanding how this is supposed to
work might go a long way to clearing up the confusion.
Is there some post-boot process that empties it? If so, there was no i/o
going on at all (zpool iostat showed all zeros) before doing rm -rf).
No. As far as I know, it's currently intentional that we don't dump the
contents of /var/pkg/download in the original boot environment.
The original boot environment already had nothing in download!
flush-content-on-success appears=true seems apparently to have no
effect on /any/ boot environment. It didn't empty download if it
had nothing in it originally, and it doesn't empty if it did. It never
seems to empty the cache, regardless. Since it take quite a long
time to actually empty it, it is probably better to do it manually
anyway, when the time is right, as they say.
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.
Cheers -- Frank
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
