Why not just move your /var/tmp to the dpool?

Seems to me that is a better solution.  In any event, I stand by my earlier
comments — changing the global default for illumos is not a good idea IMO.

On Wed, Oct 21, 2015 at 9:55 PM, Richard PALO <[email protected]> wrote:

> Le 21/10/15 23:47, Garrett D'Amore a écrit :
> > I think your problem, Richard, is that your system has put something in
> /var/tmp that is badly out of whack with its stated purpose — which is to
> provide a “temporary” location on persistent media.  Using a USB stick here
> is inappropriate for a general purpose system, unless there are no other
> options.
> >
> > If you’re doing a big compile, you *might* want to use /tmp — *IF* you
> have enough RAM.  Here’s a hint — if that big compile is *illumos* you
> better have > 4G RAM there.  These days that’s not such a big deal,
> although I used to regularly build illumos in VM environments with only 2
> or 4 GB RAM.  Which worked fine as long as $TMP was in /var.  (Mostly owing
> to enormous intermediate files created by lint.)
>
> I don't believe I have the problem indicated, with 32G ram.
> Again, my rpool is an meager Intel SSD, not meant to be intensively
> written too
> although my dpool is, being a Samsung SSD pro.
>
> After booting, swap -hs tells me I have ~40GB and:
> > richard@omnis:/home/richard$ swap -lh
> > swapfile             dev    swaplo   blocks     free
> > /dev/zvol/dsk/rpool/swap 90,2        4K     2,0G     2,0G
> > /dev/zvol/dsk/dpool/swap 90,3        4K      16G      16G
>
> at the moment, for example:
> > richard@omnis:/home/richard$ swap -hs
> > total: 1,2G allocated + 306M reserved = 1,5G used, 20G available
> > richard@omnis:/home/richard$ echo "::memstat" |pfexec mdb  -k
> > Page Summary                Pages                MB  %Tot
> > ------------     ----------------  ----------------  ----
> > Kernel                    2023186              7903   24%
> > ZFS File Data             4268560             16674   51%
> > Anon                       323104              1262    4%
> > Exec and libs                3574                13    0%
> > Page cache                  31462               122    0%
> > Free (cachelist)            93174               363    1%
> > Free (freelist)           1642014              6414   20%
> >
> > Total                     8385074             32754
> > Physical                  8385072             32754
>
> Apparently zfs has borrowed 16G from available swap.
>
> I would *presume* that in any need of swap, space will be returned
> but that, I guess, needs to be determined.
> I have ~73G avail on dpool...
>
> What I'm trying to do is preventing rpool from thrashing, using /var/tmp
> aggravates that extremely, especially behind my back.
>
> BTW:
> > richard@omnis:/home/richard/src/freebsd/include$ git show 41d91b4c
> > commit 41d91b4c7bafe88f7a31de5b7f896a4fd93552cc
> > Author: delphij <[email protected]>
> > Date:   Wed Dec 28 05:35:33 2011 +0000
> >
> >     In POSIX.1-2008:
> >
> >     P_tmpdir [OB XSI]  Default directory prefix for tempnam().
> >
> >     This macro is used in a lot of places in legacy applications,
> >     and is why we see a lot of programs written for e.g. Linux
> >     store volatile temporary files in /var/tmp and not /tmp.
> >
> >     MFC after:  2 months
> >
> > diff --git a/include/stdio.h b/include/stdio.h
> > index 0ae4d8a..02032d9 100644
> > --- a/include/stdio.h
> > +++ b/include/stdio.h
> > @@ -205,7 +205,7 @@ __END_DECLS
> >
> >  /* System V/ANSI C; this is the wrong way to do this, do *not* use
> these. */
> >  #if __XSI_VISIBLE
> > -#define        P_tmpdir        "/var/tmp/"
> > +#define        P_tmpdir        "/tmp/"
> >  #endif
> >  #define        L_tmpnam        1024    /* XXX must be == PATH_MAX */
> >  #define        TMP_MAX         308915776
> 
> 
> --
> Richard PALO
> 



-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com

Reply via email to