Mailinglist Archive: opensuse-factory (715 mails)
| < Previous | Next > |
Re: [opensuse-factory] Warning / ANNOUNCE : upcoming changes in upstream systemd regarding /media, /tmp and /var/run | /var/lock
- From: Claudio Freire <klaussfreire@xxxxxxxxx>
- Date: Wed, 28 Mar 2012 13:20:03 -0300
- Message-id: <CAGTBQpYuGzmMtZtL7eRRyEk3BOXo72+=c=6N085XM2XQrKZ4CA@mail.gmail.com>
On Wed, Mar 28, 2012 at 1:09 PM, Graham Anderson
<graham.anderson@xxxxxxxxx> wrote:
Why would it be brought to its knees? Just as tmpfs is, persistent
/tmp is also cleaned up (albeit explicitly with a cleanup script) at
boot time.
I like your sizes though (1 16th of RAM sounds ok). Notice, though,
that it means only 8M for a 128MB system. Still, from my experience
with debian, with properly behaving apps 8M should be enough. Not for
firefox as you noticed, or even chromium since any cache will eat more
than 8M.
I would only argue about battery life improvements, not performance
gains. The kernel's write cache already gets you the same performance
with a disk-based filesystem, but disk activity drains the battery.
That, and security - when sensitive information is spilled into /tmp,
having it be on tmpfs and be completely volatile improves security a
great deal. Remember that information leak recently found in
gnome-terminal (where the entire scrollback buffer was being leaked to
/tmp). That's a very important incentive for the switch to tmpfs IMO.
Easy, configure firefox to use /var/tmp.
Notice that this move will probably require a re-evaluation of the
proposed partition schemes in the installer. Now /var will be bigger,
/tmp nonexistent, and who knows how that ripples.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
<graham.anderson@xxxxxxxxx> wrote:
Of course these two times when software failed due to a full /tmp are in my
opinion much preferable to the alternative. The alternative is that when /tmp
is a physical volume and badly behaved software fills the whole volume
(usually the / volume as well) the whole system is brought to it's knees. This
has happened to me often enough from badly written scripts, bugs or software
and is the main reason I started using tmpfs /tmp.
Why would it be brought to its knees? Just as tmpfs is, persistent
/tmp is also cleaned up (albeit explicitly with a cleanup script) at
boot time.
I like your sizes though (1 16th of RAM sounds ok). Notice, though,
that it means only 8M for a 128MB system. Still, from my experience
with debian, with properly behaving apps 8M should be enough. Not for
firefox as you noticed, or even chromium since any cache will eat more
than 8M.
One other side thing, which might be nice for some users, is sometimes
noticable performance benefit from having caches (including browser cache) in
tmpfs /tmp.
I would only argue about battery life improvements, not performance
gains. The kernel's write cache already gets you the same performance
with a disk-based filesystem, but disk activity drains the battery.
That, and security - when sensitive information is spilled into /tmp,
having it be on tmpfs and be completely volatile improves security a
great deal. Remember that information leak recently found in
gnome-terminal (where the entire scrollback buffer was being leaked to
/tmp). That's a very important incentive for the switch to tmpfs IMO.
However I think it does make sense (with tangible benefits) to consider tmpfs
/tmp for most desktop users. Lets face it, if you're a power user who is going
to be using _large_ amounts of /tmp due to scripts, data manipulation,
compiling or using "power apps", you're more than capable of configuring your
system to compensate.
I see Firefox + Flash as an issue on this though, what can we do about that?
Easy, configure firefox to use /var/tmp.
Notice that this move will probably require a re-evaluation of the
proposed partition schemes in the installer. Now /var will be bigger,
/tmp nonexistent, and who knows how that ripples.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx
| < Previous | Next > |