I am sponsoring this fasttrack for Dave Plauger and Steve Sistare. The
timer is set for next Tuesday August 18, 2009. Requesting Micro/Patch
binding.
The one-pager, project specification and man page diffs are available
in the materials directory.
Sherry Moore
Template Version: @(#)sac_nextcas
+1. (I cheated -- I've seen the case materials ahead of time. :-)
This enhancement (and the need to perform subsequent actions to
decompress the crash dump) probably deserves special mention in the
Release Notes. I'd also add, in retrospect, it seems like perhaps mdb
ought to have its man pag
It's not completely clear to me from the notes whether or not to
uncompress a vmdump.N needs to be done on the machine that generated the
vmdump.N, or if it can be done anywhere else. From a support
perspective, the latter would be nice. i.e. Customer uploads a vmcore.N
to us and we uncompress
On 8/12/09, Sherry Moore wrote:
> I am sponsoring this fasttrack for Dave Plauger and Steve Sistare. The
> timer is set for next Tuesday August 18, 2009. Requesting Micro/Patch
> binding.
>
> The one-pager, project specification and man page diffs are available
> in the materials directory.
On Wed, Aug 12, 2009 at 9:28 AM, Sherry Moore wrote:
> I am sponsoring this fasttrack for Dave Plauger and Steve Sistare. ?The
> timer is set for next Tuesday August 18, 2009. ?Requesting Micro/Patch
> binding.
>
> The one-pager, project specification and man page diffs are available
> in the mater
On 8/12/09, Alan Hargreaves wrote:
> It's not completely clear to me from the notes whether or not to uncompress
> a vmdump.N needs to be done on the machine that generated the vmdump.N, or
> if it can be done anywhere else. From a support perspective, the latter
> would be nice. i.e. Customer upl
"I. Szczesniak" wrote:
> On 8/12/09, Alan Hargreaves wrote:
> > It's not completely clear to me from the notes whether or not to uncompress
> > a vmdump.N needs to be done on the machine that generated the vmdump.N, or
> > if it can be done anywhere else. From a support perspective, the latter
>
Sherry Moore wrote:
> -z y | n |
> Modify the dump configuration to control the operation |
> of savecore on reboot. The options are y (yes) to enable |
> saving core files in a compressed format, and n (no
Thanks to everyone who took the time to comment on our proposal. We have
replied to each one in private discussion, and now present this summary
of our responses.
The first 2 items result in some changes or additions to our proposal.
Garrett D'Amore wrote:
> +1. (I cheated -- I've seen the ca
Dave Plauger wrote:
>
>
>
>
> Ivek Szczesniak wrote:
>> The stdio implementation in libc is among the slowest stdio
>> versions out there. If you want to archive better performance you
>> should use the stdio implementation in libast or use mmap(2).
> This is an interesting implementation suggestio
On Thu, Aug 13, 2009 at 02:23:33PM -0700, Garrett D'Amore wrote:
> Dave Plauger wrote:
> >
> >
> >
> >
> >Ivek Szczesniak wrote:
> >>The stdio implementation in libc is among the slowest stdio
> >>versions out there. If you want to archive better performance you
> >>should use the stdio implementat
Garrett D'Amore wrote:
> Dave Plauger wrote:
> > Ivek Szczesniak wrote:
> >> The stdio implementation in libc is among the slowest stdio
> >> versions out there. If you want to archive better performance you
> >> should use the stdio implementation in libast or use mmap(2).
> > This is an interesti
Sherry Moore wrote:
> compressed file. A compressed dump file must be uncompressed
> first, by manually running savecore(1M) a second time, before
> it can be used by other tools.
Will vmdump.X be removed automatically after executing the uncompression
step?
Brian
--
Brian R
Roland Mainz wrote:
> Garrett D'Amore wrote:
>
>> Dave Plauger wrote:
>>
>>> Ivek Szczesniak wrote:
>>>
The stdio implementation in libc is among the slowest stdio
versions out there. If you want to archive better performance you
should use the stdio implementation in
Garrett D'Amore wrote:
> Roland Mainz wrote:
> > Garrett D'Amore wrote:
> >> Dave Plauger wrote:
> >>> Ivek Szczesniak wrote:
> The stdio implementation in libc is among the slowest stdio
> versions out there. If you want to archive better performance you
> should use the stdio imple
>> Ivek Szczesniak wrote:
>>> The stdio implementation in libc is among the slowest stdio
>>> versions out there. If you want to archive better performance you
>>> should use the stdio implementation in libast or use mmap(2).
>> This is an interesting implementation suggestion, but is outside the
Thanks again for your comments. Here is a summary of our responses since
yesterday.
Garrett D'Amore wrote:
> Ivek Szczesniak wrote:
>> The stdio implementation in libc is among the slowest stdio
>> versions out there. If you want to archive better performance you
>> should use the stdio implement
The latest versions of all the documentation are available in the
final-materials directory at
http://arc.opensolaris.org/caselog/PSARC/2009/330/
One pager: fast_crash_dump_1-pager.txt
Design Spec:fast_crash_dump_design.txt
Man pages: savecore.1m.diffmk.txt
dumpa
I have to go back through the specs myself, but as a result of some
training I'm in the middle of, I have to ask the question about how this
fits in with the Xen "domain dumps" initiated form the hypervisor? Does
anything eed to be done to ensure this continues to function as expected?
Regards,
Hi Alan,
The project team please correct me if I am wrong, but I believe that if
the current "domain dumps" mechanism invokes the domain's dump
algorithm, nothing additional needs to be done.
Thanks,
Sherry
On Wed, Aug 19, 2009 at 07:01:49PM +1000, Alan Hargreaves wrote:
> I have to go back thro
This case has been approved by PSARC today.
Sherry
--
Sherry Moore, Solaris Core Kernel http://blogs.sun.com/sherrym
21 matches
Mail list logo
