Mary, Are you able to test this in VBox? If so, it would be good to know when the "deleting zfs swap" workaround starts succeeding. 1.1G, 1.2G, 1.3G, ...etc
Once we know that, we can make a better informed decision. thanks, -ethan 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. > > 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 >
