An attempt to pkg image-update from snv111b to snv122 failed
miserably for a number of reasons which are probably out of
scope here. Suffice it to say that it ran out of disk space
after the third attempt.

Before starting, I was careful to make a baseline snapshot,
but rolling back to that snapshot has not freed up all the
space - this on a small disk dedicated to experimenting with
ZFS booting on SPARC. The disk is nominally 20GB.

After "zfs rollback -rR rpool/ROOT/opensola...@baseline" from
a different BE  (snv103 booted from UFS)

# zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool  17.5G  10.1G  7.39G    57%  ONLINE  -
space  1.36T   314G  1.05T    22%  ONLINE  -

# zfs list -r -o space rpool
NAME                        AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  
USEDCHILD
rpool                       7.11G  10.1G         0     20K              0      
10.1G
rpool/ROOT                  7.11G  10.1G         0     18K              0      
10.1G
rpool/ROOT/opensolaris      7.11G  10.1G      942K   10.0G              0      
68.6M
rpool/ROOT/opensolaris/opt  7.11G  68.6M         0   68.6M              0       
   0

Before the aborted pkg image-updates, the rpool took around 6GB,
so 4GB has vanished somewhere. Even if pkg put it's updates
in a well hidden place (there are no hidden directories in / ),
surely the rollback should have deleted them.

# zfs list -t snapshot
NAME                                             USED  AVAIL  REFER  MOUNTPOINT
rp...@baseline                                      0      -    20K  -
rpool/r...@baseline                                 0      -    18K  -
rpool/ROOT/opensola...@baseline                  718K      -  10.0G  -
rpool/ROOT/opensolaris/o...@baseline                 0      -  68.6M  -

The rollback obviously worked because afterwards even the
pkg set-publisher changes were gone, and other post-snapshot
files were deleted. If the worst come to the worst I could
obviously save the snapshot to a file and then restore it,
but it sure would be nice to know where the 4GB went.

BTW one image-update failure occurred because there was an X86
rpool mounted to an alternate root, and pkg somehow found it
and seemed to get confused about X86 vs. SPARC, insisting on
trying to create a menu.lst in /rpool/boot, which, of course,
doesn't exist on SPARC. I suppose this should be a bug...

Thanks -- Frank

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to