On Sun, Jun 10, 2012 at 01:51:19AM +0300, Serge wrote:
> Some people asked for a thread summary. So here it is.
[Lots of drivel, including thoroughly debunked statements, snipped.
Seriously, can't you even read what's written to you? Sorry for being
angry, but there's a limit to how many times you can have folks explain the
basics of page cache without starting to suspect malice.]
But, for the rest of us, here's a different summary. And note that, even
though I'm a strong proponent of tmpfs, I say it might be better to skip it
for wheezy -- so there's a chance this summary is not as biased.
There are exactly two downsides:
* In the "everything on one partition" scheme, there is less space available
on swap that on /.
• This is the big show-stopping problem.
* A test case was shown where tmpfs is somewhat slower (by 15%), with
reduced interactivity as well.
• Needs some investigation; is not a typical case as you'd need large
files on /tmp, nonlinear access patterns and high memory pressure at the
same time. Still, it needs to be fixed somehow.
And upsides:
* Massive speed increase for I/O operations:
• if syncs are involved: ~10000x
• if the file survives longer than 5-30 seconds: by disk's speed
• if the disk is not touched at all¹: ~10x
• if there's a writeout: depending on file/metadata ratio (no need for
journaling/barriers)
Note that these speed-ups touch I/O on /tmp only. Obviously, a process
that's CPU-bound won't see noticeable gains, and others typically do quite
a lot of things other than I/O.
* No spin-ups of laptop drives.
• There's always a spin-up even if the file has been deleted before
that 5-30 seconds passes. Laptop mode reduces these somehow but you'd
have to set dirty_expire_centisecs to some giant value to make them not
have a practical effect, risking losing actual data.
* Less wear of SSD drives.
• Contrary to Serge's claims, SSDs are not an oddity, and it's not
unlikely these will be a majority before wheezy becomes oldstable.
I intentionally did not include cases not involving typical use, like NFSed
or read-only / (we can assume a competent admin there), user errors (like
comparing spaces you configured yourself), or merits of LVM with unallocated
disk space (ie, a competent or semi-competent admin) vs dynamic swap files.
This basically boils down to:
efficiency vs failures for a newbie user.
Folks in this thread tend to agree that it's the user who can't deal with
partitions or the notion of separate space on separate filesystems who needs
the most help, as the rest of us can configure the system. Still, it'd not
a nice thing to need to do all those repetitive tweaks you may not even know
about (like mounting everything noatime, again a good thing even compared to
relatime).
So, I'd say:
* let's play it safe and not default to tmpfs for wheezy
* do it properly later
Current size defaults for /tmp are naive to the point of brokenness: with
modern systems not being expected to ever use swap, we'd want to cap /tmp at
100% of swap rather than mere 20% -- but it's tricky to tell apart that from
systems that actually do need swap for memory. And the same RAM/swap
combination can need different settings based on what the system is supposed
to do. But no matter how we tweak the ratio, it won't let some hapless user
plop a 50GB file into /tmp "because I have a lot of free space".
This is not an insurmountable problem: /tmp might use some form of overlay
that uses tmpfs for regular use and starts shunting to some area other than
swap once it sees it is being used for large files. Or alternatively, there
could possibly be a dynamic swap file on / earmarked for tmpfs pages only
(not implemented yet?). Or... Too bad, any of these solutions would need
a lot of testing, something for which there simply isn't time before wheezy.
Let's go back here after the release.
[¹]. During a short test; there'll be a spin-up later to write the directory
even if the file has been deleted already. This is O(1) though.
--
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.
Attachment:
signature.asc
Description: Digital signature