On Mon, Oct 28, 2013 at 7:07 PM, Jan Engelhardt
Indeed. So much for real-world application. But - there is a simple test for something that does happen. Try some huge (larger than just 10M) file, like a DVD image, or better, yet, a whole disk image. Example.
Cold disk caches: # sync; time (fallocate -l 500G xfs/xbig; sync); time (fallocate -l 500G ext4/xbig; sync)
real 0m0.466s user 0m0.000s sys 0m0.016s
real 0m9.482s user 0m0.000s sys 0m0.744s
# sync; time (rm -f xfs/xbig; sync); time (rm -f ext4/xbig; sync);
real 0m0.263s user 0m0.000s sys 0m0.012s
real 0m11.374s user 0m0.000s sys 0m0.160s
Warm cache:
# sync; time (fallocate -l 500G xfs/xbig; sync); time (fallocate -l 500G ext4/xbig; sync)
real 0m0.255s user 0m0.000s sys 0m0.008s
real 0m6.968s user 0m0.000s sys 0m0.596s
# sync; time (rm -f xfs/xbig; sync); time (rm -f ext4/xbig; sync);
real 0m0.236s user 0m0.000s sys 0m0.008s
real 0m8.887s user 0m0.000s sys 0m0.048s
It looks like ext4 still has some bitmaps somewhere - the hard disk LED wants to support my thesis.
Dave Chinner addressed that in the video. Per him, ext4 still uses a bitmap to track freespace. Thus fallocate has to scan through the bitmap to find free space to build the file out of and rm has to modify all those bitmaps and write them back out to disk (since you are calling sync). It seems strange that fallocate completes faster than rm? If you are interested in xfs, then watching the video I posted before is time well spent http://www.youtube.com/watch?v=FegjLbCnoBw Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org