zpool tells me the following details for my rpool: SIZE=16G ALLOC=14.5G FREE=1.36G CAP=91% and zfs tells me these stats: rpool USED=15.1G AVAIL=505M REFER=83K MOUNTPOINT=/rpool rpool/ROOT USED=14.3G AVAIL=505M REFER=21K MOUNTPOINT=legacy rpool/ROOT/opensolaris-7 USED=14.3G AVAIL=505M REFER=4.54G MOUNTPOINT=/ rpool/export, rpool/export/home, and /rpool/home/myuser USED=38.5M AVAIL=505M REFER=38.5M MOUNTPOINT=/export, /export/home, and /export/home/torti I wonder where ~10G have gone. All the subdirs in / use ~4.5G only (that might be the size of REFER in opensolaris-7), and my $HOME uses 38.5M, that''s correct. But since rpool has a size of > 15G there must be more than 10G somewhere. -- This message posted from opensolaris.org
On 02/ 6/10 11:21 AM, Thorsten Hirsch wrote:> I wonder where ~10G have gone. All the subdirs in / use ~4.5G only > (that might be the size of REFER in opensolaris-7), and my $HOME uses > 38.5M, that''s correct. But since rpool has a size of> 15G there must > be more than 10G somewhere.Do you have any old Boot Environments (BEs) around? In order to *really* empty /var/pkg/downloads, you have to delete every old BE because /var/pkg/downloads is protected by BE snapshots. Each new BE seems to take 5GB or so in /var/pkg/downloads, so it adds up fast! AFAIK there is no way to get around this. You can set a flag so that pkg tries to empty /var/pkg/downloads, but even though it looks empty, it won''t actually become empty until you delete the snapshots, and IIRC you still have to manually delete the contents. I understand that you can try creating a separate dataset and mounting it on /var/pkg, but I haven''t tried it yet, and I have no idea if doing so gets around the BE snapshot problem. Sadly this renders the whole concept of BEs rather useless if you boot from smallish SSDs or HDs - my workaround is to keep the old BEs on a backup disks, just like the old UFS days :-) (snapshots work, too). HTH -- Frank
Uhmm... well, no, but there might be something left over. When I was doing an image-update last time, my / ran out of space. I even couldn''t beadm destroy any old boot environment, because beadm told me that there''s no space left. So what I did was "zfs destroy /rpool/ROOT/opensolaris-6". After that "opensolaris-6" didn''t show up anymore in beadm list. Now there''s only "opensolaris-7" left. In this boot environment I did a "rm -rf /var/pkg/download/* /var/pkg/index/*; pkg rebuild-index" ...and maybe I also called these commands in "opensolaris-6", but I''m sure that I didn''t call them in "opensolaris-5" and prior. However I destroyed "opensolaris-5" and prior correctly with beadm. -- This message posted from opensolaris.org
On 02/06/10 08:38, Frank Middleton wrote:> AFAIK there is no way to get around this. You can set a flag so that pkg > tries to empty /var/pkg/downloads, but even though it looks empty, it > won''t actually become empty until you delete the snapshots, and IIRC > you still have to manually delete the contents. I understand that you > can try creating a separate dataset and mounting it on /var/pkg, but I > haven''t tried it yet, and I have no idea if doing so gets around the > BE snapshot problem.You can set the environment variable PKG_CACHEDIR to place the cache in an alternate filesystem.
On 02/ 6/10 11:50 AM, Thorsten Hirsch wrote:> Uhmm... well, no, but there might be something left over. > > When I was doing an image-update last time, my / ran out of space. I > even couldn''t beadm destroy any old boot environment, because beadm > told me that there''s no space left. So what I did was "zfs destroy > /rpool/ROOT/opensolaris-6". After that "opensolaris-6" didn''t show up > anymore in beadm list.When something similar happened to me when updating to snv111b, I successfully snapshotted the current BE and zfs send/recv it to a different disk, and it freed up around 5GB. No one commented on this (a long time ago now), but it would be interesting to hear from the experts about the possible aftermath of running out of space. Presumably zfs list -t snapshots doesn''t show any snapshots at all? If it does, it might be worth while deleting them to see if there are still any uneeded files in /var/pkg. On 02/ 6/10 12:33 PM, Bill Sommerfeld wrote:> > You can set the environment variable PKG_CACHEDIR to place the cache in > an alternate filesystem.Cool! Would you know when this feature became available? Thanks.
how can I delete obsolete BEs if I have run out of space and have to boot from LiveCD? On Sat, Feb 6, 2010 at 9:33 AM, Bill Sommerfeld <sommerfeld at sun.com> wrote:> On 02/06/10 08:38, Frank Middleton wrote: > >> AFAIK there is no way to get around this. You can set a flag so that pkg >> tries to empty /var/pkg/downloads, but even though it looks empty, it >> won''t actually become empty until you delete the snapshots, and IIRC >> you still have to manually delete the contents. I understand that you >> can try creating a separate dataset and mounting it on /var/pkg, but I >> haven''t tried it yet, and I have no idea if doing so gets around the >> BE snapshot problem. >> > > You can set the environment variable PKG_CACHEDIR to place the cache in an > alternate filesystem. > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-- David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100206/275652d1/attachment.html>
Oooops, some snapshots were using all the missing space. While I played around with some commands I''ve read in the ZFS Administration Guide and the ZFS FAQ, I stumbled over 6 or 7 snapshots of my opensolaris-7 be. I wonder where they come from, because I''ve never worked with snapshots so far and the auto-snapshot feature is still deactivated. Everything is fine now that I''ve deleted all snapshots. -- This message posted from opensolaris.org