On 02/03/09 09:02, Dave Miner wrote: > 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. > > George has updated the bug report with additional reasons. >> 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. > > Comment #6 stated that the issue for disabling savecore was the space taken up when BEs are cloned. When a user is asked to provide the core how does that occur ? Does he run savecore directly or update dumpadm config file. Either way once savecore is run, the contents are in savecore dir (which for now is /var/crash) and future BE updates will include the cores unless the user deletes them, i.e. the issue will occur the first time coredumps taken and the cores are not removed. >> 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090203/9866d7da/attachment.html>
