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 shou
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 i
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 sw
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 reaso
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 kin
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 belei
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 a
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
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
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
> "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
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 throug
> 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.
> 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 dum
> "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
tha
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 ar
> "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
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 arou
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"
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 m
> "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 dynamic_pager right now, and
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
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
> av
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 comple
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 t
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 an
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
> be
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
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 b
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 thi
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 coll
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
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 i
> 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 w
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 wo
> 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,
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 v
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 strongl
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
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.
>>
>
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
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 Caima
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
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
>
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 c
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 conce
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 ca
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:
s
Peter Tribble wrote:
> On Tue, Jun 24, 2008 at 8:27 PM, Dave Miner <[EMAIL PROTECTED]> wrote:
>> Keith Bierman wrote:
>>> A lot of developers use VMs of one sort or another these days, and
>>> few of them use jumpstart (especially when the entire point of the
>>> exercise is to get their feet wet o
On Tue, Jun 24, 2008 at 8:27 PM, Dave Miner <[EMAIL PROTECTED]> wrote:
> Keith Bierman wrote:
>> A lot of developers use VMs of one sort or another these days, and
>> few of them use jumpstart (especially when the entire point of the
>> exercise is to get their feet wet on new platforms, or new ver
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
>> u
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 automated provisio
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.
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
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 th
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:
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:
http://ope
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, the
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:
>>>
>>> http://opensolaris
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:
http://opensolaris.org/os/community/arc/caselog/2006/370/commitment-materials
60 matches
Mail list logo