On Mar 8, 2012, at 11:43 PM, 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?
Free memory was 7.4G before setting up the 3G tmpfs. And 161K was free after the first copy. So caching is applicable. I could maybe make a 6G or 7G tmpfs and fill that with files and see what happens. As it was, kswapd0 was extremely active, although I don't know why, certainly no swap should have been needed. Or if there's a way to disabling this caching... This was 3.3.0-0.rc3.git7.2.fc17.x86_64. > Some of the above is wonky personal observation and some of it is > probably cargo culted, but... In all three cases there was solid disk activity well after cp terminated. Timing it consistently isn't as straightforward, but btrfs and XFS were both very close at ~14 seconds solid activity after cp terminated, and no subsequent activity. ext4 post cp termination was amorphous, and lasted much longer. I think sustained testing, with a much larger number/size of files, would effectively make caching a non-factor in the results so I may give that a try. Something like 6-7G's worth of files, and initiate the four copies sequentially using &. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
