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

Re: Moving /tmp to tmpfs makes it useless

2012/5/27 Adam Borowski wrote:

> First, you're benchmarking the speed of process creation, not of file
> operations.  Starting up seq or mv takes ages compared to an in-memory
> file write.

They may be slower than in-memory operations, but they're definitely
faster than fsync(). So if there was fsync() there would have been a
noticeable difference in time. But there were no difference. So there
were no fsync(). And my HDD was not blinking during that test as well. :)

> Then, pray tell, where exactly do your tests include a fsync()?  You're
> using a 0-byte file (ie, without an actual data block).  And even if you
> added some actual data, your test would do a writeout exactly once --
> after the first rename, all data blocks would be already on the disk.

Well, you said that rename calls fsync, I checked that. :) You're saying I
should have written something there before renaming? Let's check it too:
  $ cd /path/to/empty/ext3/dir/
  $ time for i in `seq 10000`; do echo 12345 > 1; mv 1 2; rm -f 2; done
  real    0m20.125s
  user    0m4.283s
  sys     0m14.066s
  $ cd /path/to/empty/tmpfs/dir/
  $ time for i in `seq 10000`; do echo 12345 > 1; mv 1 2; rm -f 2; done
  real    0m20.005s
  user    0m4.076s
  sys     0m13.088s
Still no difference. Both tests took 19-20 seconds And again there
were no HDD blinking during the test. :) Fsync() is a myth?

> Please fix your tests, then.  Because, yes, tmpfs doesn't speed up fork(),
> exec(), setlocale(), getopt() and such.

True. These tests are useless as a benchmarks. They only prove that
there's no fsync(), nothing else. I could write that in C, but it's
pointless. Because there're still no *real* applications doing that!
And if there're no applications doing heavy rename() in /tmp then what
are we testing this for? Why are we moving *default* /tmp to tmpfs?
To make these useless tests faster?

Where's the real application becoming better after all?


Reply to: