Re: Moving /tmp to tmpfs makes it useless
2012/6/2 Roger Leigh wrote:
> These tests were all performed on current unstable using a core2 quad
> core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and
> Btrfs internally using RAID1 over 2 1TiB partitions.
Well, not fair for btrfs, but anyway, finally, some tests! Thank you
for doing them.
> 1) Checkout of several tags in a git repository
> 2) Building a package (sysvinit)
These are strange tests. We're not just talking about tmpfs, but about
/tmp on tmpfs. Are people expected to use git in /tmp? Or building packages
inside /tmp by default?
I mean, it may be a good hack for you to mount tmpfs to /mnt/tmpfs and use
it for your personal scripts, but why do you use _/tmp_ for that?
> 3) Unpacking of a large zip file
> 4) Unpacking of large uncompressed tarfile
How large were these "large" files?:
> unpack 1.2 GiB of data.
Hm, it means, that there must be _at_least_ 2GB of RAM and 4GB of swap
just for this test to work. Are you sure it's a good *default*? ;)
> Without the overhead of uncompression, making it largely CPU bound,
> tmpfs is the fastest by far.
Hah! And this makes your test the artificial corner case. I mean, default
users are not really expected to unpack zip and uncompressed tars to /tmp?
(i.e. mc won't unpack them) And personally I haven't ever seen 1+GB zip
archives (where did you got it from, just curious, or have you created
it just for the test?).
> So if you're doing a lot of I/O, tmpfs is unquestionably faster.
You're right. But who does a lot of I/O in _/tmp_?
Your tests show that if you wrote some scripts doing a lot of I/O it may
be nice to make them working on a large tmpfs mounted to i.e. /mnt/tmpfs,
but they don't explain why _/tmp_ must be mounted on tmpfs.