sanjay nadkarni (Laptop) wrote: > Joseph J VLcek wrote: >> Hey Glenn, >> >> Thanks for the feedback. >> >> Sanjay had contacted me via IRC last week. He said this bug was an issue >> and needed to be reopened. >> >> It was opened as a P1/major so I thought I would get a fix in the works >> and send out the webrev... >> >> Sanjay please address Glenn's comments. >> >> Thanks, Joe >> >> >> Glenn Lagasse wrote: >> >>> Hi Joe, >>> >>> * Joseph J VLcek (Joseph.Vlcek at Sun.COM) wrote: >>> >>>> * Please review changes for Bug 5003: >>>> >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5003 >>>> >>> I just added a comment to this bug. Before we change anything we need a >>> much clearer reason why the ZFS team views the current behaviour as a >>> bug. The reason things are the way they are is spelled out quite >>> clearly in comment #4 by Dave. As I said in my comment, there isn't any >>> data I'm aware of to suggest that we've evaluated this change in any >>> way (it's only been active for about a month). And until that's done, I >>> think it's entirely premature to just go and change this back just >>> because someone doesn't like the new behaviour. >>> >>> I would definitely be against pushing this change back until the above >>> analysis is completed. >>> > The argument that was provided in the the bug report was that it > would save boot up time *after* a panic. After a system has paniced > the priority is getting information about it. Boot up time is > irrelevant. By not enabling savecore if another panic occurred, the > contents of the first would be lost (since the core was not saved!). > While it is probable that another panic might occur before the first > one can be saved, that window is much smaller. >
We've had this discussion twice previously (once here in June, and a couple of months back on nv-users) and I'm not going to repeat it. You haven't raised any new points. Cascading dumps are the one known risk, and we're lacking data (I've asked services) to indicate that's a sufficiently common problem to bias for. > The issue of cores taking up unnecessary space when a rpool/ROOT is > cloned is valid. But disabling savecore does not address it. Either the > user has to run this by hand everytime (bad!!) or once they enable this > functionality all subsequent clones now have the issue until they > disable it. > I don't understand what you're arguing for here. > Dave's suggested change of having a separate dataset for this sounds good. > What I would like to see is that the forthcoming BE ARC case includes this as a proposed change (perhaps also with a similar coreadm change) and we discuss it there. Meantime, we leave this alone. Dave
