:: Re: [DNG] merging /tmp
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Erik Christiansen
日付:  
To: dng
題目: Re: [DNG] merging /tmp
On 27.11.18 22:28, Rick Moen wrote several juciy tips, including:
> (Depending on your system, you probably want to ensure that /var/lib
> and /var/spool are served from elsewhere, either separate filesystems
> of their own or symlinks to trees elsewhere /like to dirs under /home
> or some such.)


I'm still getting my head around the concept of having separate /var and
then symlinking /var/spool back into /home. Admittedly, I do in effect
something like that for mail, as procmail (invoked directly by postfix)
dumps 99.9% of mail to ~/mail/*, so only the smallest residue hits
/var/spool/mail/erik . That outlier has been a backup nuisance, which your
method obviates.

Looking at /var/lib for the first time in three decades, I see the merit
of that symlink, at least for backup purposes.

> > Growth of /tmp was never a problem, as removal of several day old tmp
> > files was/is a standard cronjob, at least after you've been bitten once.
>
> I actually think tmpfs for /tmp is a fine idea, provided (1) you are
> aware of what'll happen if it balloons, and (2) you're OK with it being
> backed by volatile storage and aren't surprised by it being empty after
> reboots including unplanned ones. The speed gain is serious.
>
> If nervous about all of /tmp being volatile, you could, e.g., have
> subdir /var/volatile only mounted as tmpfs.
>
> For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of
> any kind on near-future server systems because of intended use of only
> SSDs, no spinning rust at all. I don't have hard data, but suspect that
> the wear on SSDs from swap activity is substantial to a degree that
> outweighs swap's functional utility -- for my use-case, at least. I
> intend to have a go at a style of operation where running out of
> physical RAM means the OOM killer gets loose for a while, and see how
> that goes. The implicity assumption is 'I'll try to avoid that by
> having enough RAM and not running tasks configured so they're likely to
> blow up and drive the system into swap.' My metrics say that I haven't
> been driving into swap, so it's probably a reasonable stance.


Now that is very appealing. It feels like the way things should be.
It'll take a while to marshall the round-tuits, but it's now on the
to-do list.

Many thanks for the insight.

Erik