Thank you both for following through with this discussion. > On 10/3/07, David Bustos <David.Bustos at sun.com> > wrote: > > Word on the street is that the kernel dumps to the > end of the swap > > device. Since we start swapping from the > beginning, it's possible to > > clobber the dump, but less likely with larger swap > devices. Apparently > > there has been talk of fixing this up, but it > doesn't seem to be > > a priority.
Yes, this does seem like a bit of a problem then. A bit of a race condition, but perhaps not in the normal programming definition of the term. In this case, you're racing to get the dump out before swap usage catches up. Large swap devices help mitigate this for sure, but large-memory systems (specifically those with large amounts of said memory in constant use) exacerbates it again. > There is a prototype out there (posted to the list > yesterday) of using > SMF instead of vfstab for handling mounts. This > could make it really > easy to get the dependencies right without > unnecessarily slowing down > the boot process. An application that is known to > need to use swap > could just set the appropriate dependency. Since it is the move to SMF that seems to have gotten us here, leveraging it to get us back out again makes sense. (I'm not sure how I feel yet about losing vfstab and putting this into an SMF manifest or whatever, but that's a very different discussion, only hinted at below.) > Presumably this would mean that dumpadm would be > responsible for > updating SMF dependencies or there could be multiple > dumpadm services > (dumpadm:swap, dumpadm:dedicated) that do the right > thing based upon > the dumpadm.conf or replacement properties in the > service properties. Makes sense. I hope the sysadmin community will be consulted to ensure the interfaces/tools for this (the service properties) are useful and robust. ZFS already confused things to some degree; let's not continue to muddy the waters. While I'm learning to adapt more, others may not be so kind. > One of the things previously discussed at > sysadmin-discuss was having > savecore (called by dumpadm service) save to an NFS > mounted directory. > It seems as though at path dependency could form an > implicit > ependency on any required mounts (be they vfstab, > smf, autofs, or > something else) without having to analyze and muck > with the > dependencies when file system mount configurations > are changed. This may be more of a side-note to Mike, but I think we need to consider these implications when we (in the sysadmin community) work on the best practices documentation. At least for now, it seems that making the dump device something other than swap is very important. Maybe less so when this gets resolved, but if it is a low priority... David, when you say "low priority," what kind of time frame are we looking at? Six months? Three years? I only ask this because the time-frame implied by "low" is very dependent on workload, and I have no idea how much the SMF team have on their plate. Thanks again. Rainer This message posted from opensolaris.org
