On Fri, Mar 9, 2012 at 10:11 AM, David Quigley <selinux@xxxxxxxxxxxxxxx> wrote: > On 03/09/2012 08:42, Przemek Klosowski wrote: >> >> On 03/09/2012 01:43 AM, Adam Williamson wrote: >>> >>> On Thu, 2012-03-08 at 22:19 -0700, Chris Murphy wrote: >>>> >>>> I'm not sure how useful 'time' is as a benchmark for file copies. >>> >>> >>> Don't file transfers get cached and return to a console as 'complete' >>> long before the data is ever written, sometimes? >>> >>> I'm pretty sure you sometimes hit the case where you copy 200MB to a USB >>> stick, it returns to the console pretty fast, but the light on the stick >>> is still flashing, and if you run 'sync', it sits there for quite a >>> while before returning to the console, indicating the transfer wasn't >>> really complete. So I'm not sure 'time'ing a 'cp' is an accurate test of >>> actual final-write-to-device. >> >> >> That is true---but in that case, we could flush the disks. and then >> time the operation followed by another flush, i.e.: >> >> sync; time (cp ...; sync) >> >> I assume that the old-time Unix superstition of calling sync three >> times no longer applies :) >> >> Perhaps a dedicated disk benchmark like bonnie++ would be a better >> test, though. > > > > If you want to look seriously into file-system benchmarking I would suggest > looking into the work done by the fsbench people at Stony Brook University's > Filesystem and Storage Lab (FSL). There is a survey paper there for the last > decade of FS benchmarks and their short commings and what should be > addressed. > > > http://www.fsl.cs.sunysb.edu/project-fsbench.html > fsbench is amazing, I also use fio and fs_mark to test various things. But these are artificial workloads! These numbers don't mean a damned thing to anybody, the only way you know if a fs is going to work for you is if you run your application on a couple of fses and figure out which one is faster for you! For example if you mostly compile kernels, btrfs is fastest. However if you mostly use a fs for your virt images, don't use btrfs! It's all a matter of workloads and no amount of benchmarking is going to be able to tell you if your pet workload is going to work well at all. The work that we file system developers do with benchmarking is to stress particular areas of our respective filesystems. For example, with Dave's tests he was testing our ability to scale as the amount of metadata gets ridiculously huge. He has exposed real problems that we are working on fixing. However these real problems are things that I imagine 99% of you will never run into, and therefore should not be what you use to base your decisions on. So let's try to remember that benchmarks mean next to nothing to real users, unless watching iozone output happens to be what you use your computer for. Thanks, Josef -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
