[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

-- 
  Serge


Reply to: