Jan:

Let me go and check this out and get back to you.  I had a couple of 
systems around 1GB of memory and I will do some AI install and find out. 
  Stay tuned.

I know that 1 GB swap fails for sparc.


jan damborsky wrote:
> Hi Mary,
> 
> 
> On 03/25/09 18:38, mary ding wrote:
>> Ethan and William:
>>
>> I agree with Ethan about this.  We shouldn't require user to do 
>> anything manual or customize manifest to workaround this ugly zfs bug.
>>
>> So far, this is what I found out for sparc and x86.  I hit this bug 
>> everytime when my system had more than 700 MB for sparc and x86.  With 
>> 512 MB, the install works but it is very slow.
>>
>> With system that had 1 GB of memory, if I delete zfs swap, IPS install 
>> will fail and run out of memory.
> 
> Do you happen to know if the behavior is the same
> for sparc & x86 systems with 1GB of memory ?
> 
> I am asking, since after fix for 4166 bug was integrated,
> AI is supposed to work on x86 systems with 1GB of memory
> without swap device. If it fails for you, might I please
> take a look at x86 machine in question ?
> 
> Thank you,
> Jan
> 
>>
>> If I do this on system with 2 GB of memory and delete zfs swap, the 
>> install works.
>>
>> If you need any help testing the workaround, I will be happy to try 
>> them out since I had machines available for testing purpose.
>>
>>
>>
>>
>>
>> Ethan Quach wrote:
>>>
>>>
>>> William Schumann wrote:
>>>> RE: Bugzilla bug 6084 AI fails due to solaris.zlib becoming corrupt 
>>>> during install
>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6804
>>>>
>>>> 6817316 data corruption seen with swapping to a zvol
>>>> http://monaco.sfbay/detail.jsf?cr=6817316
>>>>
>>>> The problem occurs when a ZFS volume is used for swap in the 
>>>> Automated Installer.  There is an alternative swap solution - to use 
>>>> a slice for swap instead of a ZFS volume.
>>>>
>>>> Currently, AI follows the logic of creating swap on a ZFS volume if 
>>>> there is enough space.  If not, the target partition (x86) or disk 
>>>> (SPARC) slice 1 will be used for swap if there is enough space.
>>>>
>>>> What I propose here to add a feature: a new AI manifest element 
>>>> <target_device_swap_slice_number>, which would force the creation of 
>>>> swap on an indicated slice instead of on a ZFS volume.
>>>
>>> This is a workaround, but this solution would seem to require that
>>> the user manually do something to work around the issue after hitting
>>> it.  Could we devise a work around that works out of the box?  Or at
>>> least works out of the box for most scenarios?
>>>
>>> For example, for systems with XX Gb memory, we could still create the
>>> swap zvol, and just not add it during the microroot.  I think Mary's
>>> found that XX so far equals 2Gb, but she doesn't really have any
>>> systems with anything between 1Gb and 2Gb of memory.  With some VBox
>>> testing perhaps we can find that number to be something smaller, and
>>> then our bug case would only be for systems with memory between
>>> 700Mb and XXGb --and only there would we institute some really
>>> ugly hack.  For those cases we could resort to what you've described
>>> above, or just move our 700Mb number up to XXGb.
>>>
>>>
>>> thanks,
>>> -ethan
>>>
>>>>
>>>> An advantage of this approach is that, since we are as yet uncertain 
>>>> of which configurations will exhibit bug 6084, there is a simple 
>>>> manual configuration change to work around it.  It would also serve 
>>>> as an AI feature (although perhaps not a terribly interesting one).
>>>>
>>>> I would estimate a day of work to code this and do unit testing.  
>>>> The additional risk would be small.
>>>>
>>>> I will mention here that the swapping to a zvol bug needs to be 
>>>> fixed, and that perhaps we shouldn't be thinking in terms of a 
>>>> workaround, but a high priority fix.
>>>>
>>>> Any feedback would be appreciated,
>>>> William
>>>> _______________________________________________
>>>> caiman-discuss mailing list
>>>> caiman-discuss at opensolaris.org
>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
> 


Reply via email to