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?
--
Serge
Reply to: