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
