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
