Yeah, in snv_171 this seems to be addressed. I filled both a root pool and a non-root pool, and was able to delete a file and free up space on both. So, it looks like CR6976827 has addressed the issue.
/jb On Aug 9, 2011, at 10:25 AM, Jesse Butler wrote: > > On Aug 9, 2011, at 10:20 AM, Drew Fisher wrote: > >> >> >> On 8/9/11 7:55 AM, Darren Kenny wrote: >>> On 09/08/2011 14:30, Drew Fisher wrote: >>>> Good morning! >>>> >>>> I wanted to discuss 7032205 >>>> (http://monaco.sfbay.sun.com/detail.jsf?cr=7032205) with the group to >>>> try to get a consensus with the right approach to take. What I was >>>> thinking was setting a value of 1% of the total size of the root pool, >>>> with an upper bound of 1gb. >>>> >>>> For the ultra small disks (32gb SSD), 1% is 320MB. For huge disks (2tb >>>> HDD), we'd cap at 1gb. This would provide admins a little bit of >>>> breathing room for a full root pool. The problem with doing something >>>> like this is some admins would really appreciate the installers doing >>>> something like this for them while other admins want to customize each >>>> and every single aspect of their install. This leads to a few approaches: >>>> >>>> 1: Set up an ICT to do the quota setting *after* we successfully >>>> install - this is so we can complete the install without zfs getting in >>>> the way. >>>> >>>> 2: Set up controller.py to add an additional zpool option for the quota >>>> on the root pool. >>>> >>>> 3: other? Add something to the default manifest for AI and force the >>>> option for GUI and TI? DTD entries specifically for this? >>>> >>>> Please let me know what you folks think! >>> Honestly, and I've said this before, I feel that this is a ZFS bug and >>> should be >>> fixed in ZFS - even with a 100% full disk it should be possible to make >>> space - >>> but it isn't, there really should be a 'buffer' in there. >> >> I totally agree with the sentiment that this is a ZFS issue. Perhaps we >> don't need to do anything on our end, aside from escalate the CR already >> assigned to ZFS. > > The current situation is unclear to me... obviously, no one seems to be on > the initial RFE (6803038), but 6976827, which was integrated in snv_167) at > least by synopsis, seems to be a fix. Maybe we should check into this first. > > Back to the point here - I think it's a good workaround to set a quota on the > rpool, but if it's not necessary I doubt it's required even optionally. > > /jb > >> >>> >>> But, if we are going to have to go down this route, then I think what you're >>> suggesting sounds like a good start and I would prefer option 2, as long as >>> there isn't a quota already specified by the user. This gives the best of >>> both >>> worlds - i.e. automatically settable while leaving it possible to override. >> >> Thanks, Darren. >> >> -Drew >> _______________________________________________ >> caiman-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
