On Sun, May 27, 2012 at 05:21:04AM +0300, Serge wrote: > 2012/5/27 Adam Borowski wrote: > > > I think that box had jfs, but other filesystems are no different: for > > example, ext* will fsync() during a rename() call behind your back even > > if you don't request it, forcing every file to hit the disk > > This is easy to check: > $ cd /path/to/tmpfs > $ touch 1 > $ time for i in `seq 10000`; do mv $i $((i+1)); done > real 0m9.760s > user 0m2.727s > sys 0m6.773s > $ cd /path/to/ext3 > $ touch 1 > $ time for i in `seq 10000`; do mv $i $((i+1)); done > real 0m9.624s > user 0m2.679s > sys 0m6.877s > I don't see major difference. Both tests gave 9.5-9.8s range between runs. > Maybe your filesystem is to blame? 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. 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. > > So don't tell me real filesystems are "almost as good" as tmpfs > > Tests tell you that. :) Please fix your tests, then. Because, yes, tmpfs doesn't speed up fork(), exec(), setlocale(), getopt() and such. > Actually real filesystem is not just "as good", it's better, because it > does not eat memory and slow down other running programs when > writing to disk. I guess you missed the whole rest of this flamewar. Tmpfs does eat as much (actually, slightly less) space than real filesystems, and if you didn't give it that space, it's your fault. Or perhaps, d-i's defaults', as 20% of swap is indeed little if mosts systems don't use swap at all and allocated swap space is what /tmp would otherwise get 100% of. -- 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