Jlliagre,

A few points, becasue this a a particular topic that really annoys me when people get it wrong.

1. My original statement that you don't need any swap for core files is 100% accurate. The (updated) underlining of "need" should give an indication that I saying that there are alternatives and I do not feel this was in any way misleading. In the blog I linked to this is also explained. I never said you couldn't or shouldn't use swap for it. I was pointing out that it does not need to be included in the decision of appropriate swap size.

2. Yes, you can use a dedicated partition for the dump device and there are may reasons why you might choose to do that (or not to). I diagree with the statement that there is no reason not to use swap.

3. My argument had nothing whatsoever to do with saving disk space, it was a obeservation base on the fallacious claim that 2x memory is required for swap, and one of the reasons given was that you need swap for savecores, this is simply untrue.

4. It is easy to make logical arguments based on half truth. The reason dumpadm was introduced to allow this behaviour was indeed based in part on the fact that swap was not large enough to hold coredumps. However with full disclosure you would note that the reason that this was the case was becasue the swap space was often reduced becasue it was not needed operationally because physical memory could be used and therefore not allocated.

5. You can to some extent control the size of a core, by restricting the contents:

Code:

     -c content-type         Modify  the  dump  configuration  so
                             that  the crash dump consists of the
                             specified dump content.  The content
                             should be one of the following:

                             kernel          Kernel memory  pages
                                             only.

                             all             All memory pages.

                             curproc         Kernel memory pages,
                                             and the memory pages
                                             of the process whose
                                             thread was currently
                                             executing on the CPU
                                             on  which  the crash
                                             dump was  initiated.
                                             If  the  thread exe-
                                             cuting on  that  CPU
                                             is  a  kernel thread
                                             not associated  with
                                             any   user  process,
                                             only  kernel   pages
                                             will be dumped.

And unless you specify "all" you will never need as much space as you have memory. From experience I agree with pupp, it will only be a few gigs for the standard "kernel pages" dump with the possible exception where an unconstrained ARC cache is used for ZFS.

6. The argument about saving disk really doesn't apply in most instances where dumpadm is actually used. In my systems one of the main reasons for using dumpadm to specify a partition other than swap is becasue swap may be configured to use high speed external disks, a SAN for example, becasue I want performace to be as good as possible if I didn't use enough memory or I have an occasional tasks which throws me over the physical memory boundary, or as is more common I am using ISM and I need disk backed swap. If I am not booting from SAN I defintely don't want this on my local disk(s). Under certain circumstances the external storage would not be available after a crash so I do want to dump to local disk. I might need the core file to debug or for a support case. Secondly if I use a dedicated partition and I don't have enough space to save the core file I can at any time manually invoke savecore and save the file after freeing up space, or after using dumpadm to specify an alternate location, if I use swap it's gone once the server comes up.

At the end of the day I was talking about using disk backed swap, not about kernel dumps, and I had really hoped to avoid having to go into deatil on that topic.

I still maintain that swap should be dimensioned based on operational requirements of the system and applications, the operational requirements do not need to, but may, include space for core dumps.