Dave Miner wrote:
jan damborsky wrote:
...
[2] dump and swap devices will be considered optional
dump and swap devices will be considered optional during
fresh installation and will be created only if there is
appropriate space available on disk provided.
Minimum disk space required will
Jeff Bonwick wrote:
To be honest, it is not quite clear to me, how we might utilize
dumpadm(1M) to help us to calculate/recommend size of dump device.
Could you please elaborate more on this ?
dumpadm(1M) -c specifies the dump content, which can be kernel, kernel plus
current process, or all
On Jun 30, 2008, at 19:19, Jeff Bonwick wrote:
Dump is mandatory in the sense that losing crash dumps is criminal.
Swap is more complex. It's certainly not mandatory. Not so long ago,
swap was typically larger than physical memory.
These two statements kind of imply that dump and swap are
David Magda wrote:
Quite often swap and dump are the same device, at least in the
installs that I've worked with, and I think the default for Solaris
is that if dump is not explicitly specified it defaults to swap, yes?
Is there any reason why they should be separate?
I beleive
David Magda wrote:
On Jun 30, 2008, at 19:19, Jeff Bonwick wrote:
Dump is mandatory in the sense that losing crash dumps is criminal.
Swap is more complex. It's certainly not mandatory. Not so long ago,
swap was typically larger than physical memory.
These two statements kind of imply
On Wed, Jul 2, 2008 at 10:08 AM, David Magda [EMAIL PROTECTED] wrote:
Quite often swap and dump are the same device, at least in the
installs that I've worked with, and I think the default for Solaris
is that if dump is not explicitly specified it defaults to swap, yes?
Is there any reason why
Mike Gerdts wrote:
On Wed, Jul 2, 2008 at 10:08 AM, David Magda [EMAIL PROTECTED] wrote:
Quite often swap and dump are the same device, at least in the
installs that I've worked with, and I think the default for Solaris
is that if dump is not explicitly specified it defaults to swap, yes?
sanjay nadkarni (Laptop) wrote:
Mike Gerdts wrote:
On Wed, Jul 2, 2008 at 10:08 AM, David Magda [EMAIL PROTECTED] wrote:
Quite often swap and dump are the same device, at least in the
installs that I've worked with, and I think the default for Solaris
is that if dump is not
Kyle McDonald wrote:
David Magda wrote:
Quite often swap and dump are the same device, at least in the
installs that I've worked with, and I think the default for Solaris
is that if dump is not explicitly specified it defaults to swap, yes?
Is there any reason why they should be
Hi Jeff,
Jeff Bonwick wrote:
Neither swap or dump are mandatory for running Solaris.
Dump is mandatory in the sense that losing crash dumps is criminal.
I think that installer should be tolerant in this point and shouldn't
refuse to proceed with installation if user doesn't provide enough
Mike Gerdts wrote:
On Mon, Jun 30, 2008 at 9:19 AM, jan damborsky [EMAIL PROTECTED] wrote:
Hi Mike,
Mike Gerdts wrote:
On Wed, Jun 25, 2008 at 11:09 PM, Jan Damborsky [EMAIL PROTECTED]
wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would
Dave Miner wrote:
I agree - I am just thinking, if it is fine in general to allow
normal non-experienced user (who is the target audience for Slim
installer) to run system without swap. To be honest, I don't know,
since I am not very experienced in this area.
If people agree that this is not
Mike Gerdts wrote
By default, only kernel memory is dumped to the dump device. Further,
this is compressed. I have heard that 3x compression is common and
the samples that I have range from 3.51x - 6.97x.
My samples are in the range 1.95x - 3.66x. And yes, I lost
a few crash dumps on a box
Jeff Bonwick wrote:
Neither swap or dump are mandatory for running Solaris.
Dump is mandatory in the sense that losing crash dumps is criminal.
Agreed on that point, I remember all to well why I was in Sun Service
the days when the first dump was always lost because savecore didn't
used to
On Tue, Jul 1, 2008 at 5:56 AM, Darren J Moffat [EMAIL PROTECTED] wrote:
Instead we should take it completely out of their hands and do it all
dynamically when it is needed. Now that we can swap on a ZVOL and ZVOLs
can be extended this is much easier to deal with and we don't lose the
benefit
Mike Gerdts wrote:
On Tue, Jul 1, 2008 at 5:56 AM, Darren J Moffat [EMAIL PROTECTED] wrote:
Instead we should take it completely out of their hands and do it all
dynamically when it is needed. Now that we can swap on a ZVOL and ZVOLs
can be extended this is much easier to deal with and we
On Tue, Jul 1, 2008 at 7:31 AM, Darren J Moffat [EMAIL PROTECTED] wrote:
Mike Gerdts wrote:
On Tue, Jul 1, 2008 at 5:56 AM, Darren J Moffat [EMAIL PROTECTED]
wrote:
Instead we should take it completely out of their hands and do it all
dynamically when it is needed. Now that we can swap on
On Tue, Jul 1, 2008 at 8:10 AM, Mike Gerdts [EMAIL PROTECTED] wrote:
On Tue, Jul 1, 2008 at 7:31 AM, Darren J Moffat [EMAIL PROTECTED] wrote:
Mike Gerdts wrote:
On Tue, Jul 1, 2008 at 5:56 AM, Darren J Moffat [EMAIL PROTECTED]
wrote:
Instead we should take it completely out of their hands
Mike Gerdts wrote:
Not at all, and I don't see how you could get that assumption from what I
said. I said dynamically when it is needed.
I think I came off wrong in my initial message. I've seen times when
vmstat reports only megabytes of free swap while gigabytes of RAM were
available.
Darren J Moffat wrote:
Mike Gerdts wrote:
Not at all, and I don't see how you could get that assumption from what I
said. I said dynamically when it is needed.
I think I came off wrong in my initial message. I've seen times when
vmstat reports only megabytes of free swap while
On Jul 1, 2008, at 10:55 AM, Miles Nordin wrote:
I don't think it's overrated at all. People all around me are using
this dynamic_pager right now, and they just reboot when they see too
many pinwheels. If they are ``quite happy,'' it's not with their
pager.
I often exist in a sea of mac
On Tue, 1 Jul 2008, Miles Nordin wrote:
I don't think it's overrated at all. People all around me are using
this dynamic_pager right now, and they just reboot when they see too
many pinwheels. If they are ``quite happy,'' it's not with their
pager.
While we have seen these pinwheels under
Miles Nordin wrote:
re == Richard Elling [EMAIL PROTECTED] writes:
re Mike, many people use this all day long and seem to be quite
re happy. I think the slow death spiral might be overrated :-)
I don't think it's overrated at all. People all around me are using
this
bf == Bob Friesenhahn [EMAIL PROTECTED] writes:
re == Richard Elling [EMAIL PROTECTED] writes:
re If you run out of space, things fail. Pinwheels are a symptom
re of running out of RAM, not running out of swap.
okay. But what is the point?
Pinwheels are a symptom of thrashing.
On Tue, 1 Jul 2008, Miles Nordin wrote:
okay. But what is the point?
Pinwheels are a symptom of thrashing.
They seem like the equivalent of the meaningless hourglass icon to me.
Pinwheels are not showing up when the OS is returning ENOMEM.
Pinwheels are not ``things fail'', they are
bf == Bob Friesenhahn [EMAIL PROTECTED] writes:
bf What is the relationship between the size of the memory
bf reservation and thrashing?
The problem is that size-capping is the only control we have over
thrashing right now. Maybe there are better ways to predict thrashing
than through
To be honest, it is not quite clear to me, how we might utilize
dumpadm(1M) to help us to calculate/recommend size of dump device.
Could you please elaborate more on this ?
dumpadm(1M) -c specifies the dump content, which can be kernel, kernel plus
current process, or all memory. If the dump
The problem is that size-capping is the only control we have over
thrashing right now.
It's not just thrashing, it's also any application that leaks memory.
Without a cap, the broken application would continue plowing through
memory until it had consumed every free block in the storage pool.
On Tue, 1 Jul 2008, Miles Nordin wrote:
bf What is the relationship between the size of the memory
bf reservation and thrashing?
The problem is that size-capping is the only control we have over
thrashing right now. Maybe there are better ways to predict thrashing
than through
bf == Bob Friesenhahn [EMAIL PROTECTED] writes:
bf sequential access to virtual memory causes reasonably
bf sequential I/O requests to disk.
no, thrashing is not when memory is accessed randomly instead of
sequentially. It's when the working set of pages is too big to fit in
physical
On Tue, 1 Jul 2008, Miles Nordin wrote:
But, just read the assumptions. They're not really assumptions.
They're just definitions of what is RAM, and what is a time-sharing
system. They're givens.
In today's systems with two or three levels of cache in front of
RAM, variable page sizes, and
Hi Darren,
Darren J Moffat wrote:
Jan Damborsky wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in Caiman
installer is concerned.
[1] Following
jan damborsky wrote:
I think it is necessary to have some absolute minimum
and not allow installer to proceed if user doesn't
provide at least minimum required, as we have to make
sure that installation doesn't fail because of space
issues.
I very strongly disagree.
Neither swap or dump are
Darren J Moffat wrote:
jan damborsky wrote:
I think it is necessary to have some absolute minimum
and not allow installer to proceed if user doesn't
provide at least minimum required, as we have to make
sure that installation doesn't fail because of space
issues.
I very strongly disagree.
Hi Mike,
Mike Gerdts wrote:
On Wed, Jun 25, 2008 at 11:09 PM, Jan Damborsky [EMAIL PROTECTED] wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in
I agree - I am just thinking, if it is fine in general to allow
normal non-experienced user (who is the target audience for Slim
installer) to run system without swap. To be honest, I don't know,
since I am not very experienced in this area.
If people agree that this is not issue at all, I
On Mon, Jun 30, 2008 at 9:19 AM, jan damborsky [EMAIL PROTECTED] wrote:
Hi Mike,
Mike Gerdts wrote:
On Wed, Jun 25, 2008 at 11:09 PM, Jan Damborsky [EMAIL PROTECTED]
wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following
Neither swap or dump are mandatory for running Solaris.
Dump is mandatory in the sense that losing crash dumps is criminal.
Swap is more complex. It's certainly not mandatory. Not so long ago,
swap was typically larger than physical memory. But in recent years,
we've essentially moved to a
On Mon, Jun 30, 2008 at 04:19:15PM -0700, Jeff Bonwick wrote:
(2) In a virtualized environment, a better way to get a crash dump
would be to snapshot the VM. This would require a little bit
of host/guest cooperation, in that the installer (or dumpadm)
would have to know that it's
Hello Mike,
Wednesday, June 25, 2008, 9:36:16 PM, you wrote:
MG On Wed, Jun 25, 2008 at 3:09 PM, Robert Milkowski [EMAIL PROTECTED] wrote:
Well, I've seen core dumps bigger than 10GB (even without ZFS)... :)
MG Was that the size in the dump device or the size in /var/crash? If it
MG was the
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in Caiman
installer is concerned.
[1] Following formula would be used for calculating
swap and dump sizes:
Jan Damborsky wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in Caiman
installer is concerned.
[1] Following formula would be used for
On Wed, Jun 25, 2008 at 11:09 PM, Jan Damborsky [EMAIL PROTECTED] wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in Caiman
installer is concerned.
On Wed, Jun 25, 2008 at 3:09 PM, Robert Milkowski [EMAIL PROTECTED] wrote:
Well, I've seen core dumps bigger than 10GB (even without ZFS)... :)
Was that the size in the dump device or the size in /var/crash? If it
was the size in /var/crash, divide that by the compress ratio reported
on the
On Wed, Jun 25, 2008 at 3:36 PM, Mike Gerdts [EMAIL PROTECTED] wrote:
On Wed, Jun 25, 2008 at 3:09 PM, Robert Milkowski [EMAIL PROTECTED] wrote:
Well, I've seen core dumps bigger than 10GB (even without ZFS)... :)
Was that the size in the dump device or the size in /var/crash? If it
was the
Hello Mike,
Wednesday, June 25, 2008, 2:09:31 PM, you wrote:
MG dump should scale with memory size, but the size given is completely
MG overkill. On very active (heavy kernel activity) servers with 300+ GB
MG of RAM, I have never seen a (compressed) dump that needed more than 8
MG GB. Even
Hello Darren,
Wednesday, June 25, 2008, 1:19:53 PM, you wrote:
DJM Jan Damborsky wrote:
Thank you very much all for this valuable input.
Based on the collected information, I would take
following approach as far as calculating size of
swap and dump devices on ZFS volumes in Caiman
Hi Lori,
Lori Alt wrote:
Richard Elling wrote:
Hi Jan, comments below...
jan damborsky wrote:
Hi folks,
I am member of Solaris Install team and I am currently working
on making Slim installer compliant with ZFS boot design specification:
On Mon, Jun 23, 2008 at 11:58 AM, Lori Alt [EMAIL PROTECTED] wrote:
The Caiman team can make their own decision here, but we
decided to be more hard-nosed about disk space requirements in the
legacy install. If the pool is too small to accommodate the recommended
swap and dump zvols, then
Mike Gerdts wrote:
On Mon, Jun 23, 2008 at 11:58 AM, Lori Alt [EMAIL PROTECTED] wrote:
The Caiman team can make their own decision here, but we
decided to be more hard-nosed about disk space requirements in the
legacy install. If the pool is too small to accommodate the recommended
swap
jan damborsky wrote:
Hi Lori,
Lori Alt wrote:
The Caiman team can make their own decision here, but we
decided to be more hard-nosed about disk space requirements in the
legacy install. If the pool is too small to accommodate the recommended
swap and dump zvols, then maybe this system
Lori Alt wrote:
Mike Gerdts wrote:
On Mon, Jun 23, 2008 at 11:58 AM, Lori Alt [EMAIL PROTECTED] wrote:
The Caiman team can make their own decision here, but we
decided to be more hard-nosed about disk space requirements in the
legacy install. If the pool is too small to accommodate
On Tue, 2008-06-24 at 09:41 -0700, Richard Elling wrote:
IMHO, you can make dump optional, with no dump being default.
Before Sommerfeld pounces on me (again :-))
actually, in the case of virtual machines, doing the dump *in* the
virtual machine into preallocated virtual disk blocks is silly.
Keith Bierman wrote:
On Jun 24, 2008, at 11:01 AM, Dave Miner wrote:
I doubt we'd have interest in providing more configurability in the
interactive installer. As Richard sort of points out subsequently,
most
people wouldn't know what to do here, anyway, and the ones who do
usually use
Richard Elling wrote:
Hi Jan, comments below...
jan damborsky wrote:
Hi folks,
I am member of Solaris Install team and I am currently working
on making Slim installer compliant with ZFS boot design specification:
55 matches
Mail list logo
