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.
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
