On Fri, Mar 13, 2009 at 9:43 PM, Greg Freemyer <[email protected]> wrote: > On Fri, Mar 13, 2009 at 11:58 AM, Manish Katiyar <[email protected]> wrote: >> On Fri, Mar 13, 2009 at 9:19 PM, Greg Freemyer <[email protected]> >> wrote: >>> On Fri, Mar 13, 2009 at 11:23 AM, Vineet Agarwal >>> <[email protected]> wrote: >>>> Hello Everyone, >>>> >>>> Well i have tested the code of memcopy without sync_dirty_buffers() >>>> No data corruption was reported. So it is fine . >>>> But still the downtime for relocation is still high as compared to cp. >>>> >>>> test_256.db is a 256 Mb file that is relocated. >>>> >>>> [r...@fscops Memcopy]# time cp /test_256.db /mnt >>>> real 0m17.577s >>>> user 0m0.017s >>>> sys 0m1.251s >>>> >>> Hello Greg ,
>>> Vineet, >>> >>> You have to remember all the caches that are involved with disk i/o. >>> When benchmarking you have to ensure all the caches are empty before >>> AND after the timing is performed. >>> >>> ie. Having a copy of test_256.db in the cache before you start would >>> mean it does not have to be read from disk, but simply pulled from >>> ram. >>> >>> Not emptying the cache at the end means all that your timing is the >>> population of the write cache. Need to include the time it takes to >>> get the data to disk. >>> Thank you for your help . well i had copied the file test_256.db after a fresh reboot. Moreover, relocation of the file using memcopy algorithm was also performed after a successful remount of file system. As i thought all pages would have got synced at the time of unmount. >>> I can't remember offhand how to flush the read cache >> >> By any chance it is setting 1 to /proc/sys/vm/drop_caches ?? >> > > Looks right. Per http://linux-mm.org/Drop_Caches > > Your script should have: > > # flush the dirty blocks out to disk > sync > > # flush the cache of all non-dirty blocks. ie. flush the read cache > echo 3 > /proc/sys/vm/drop_caches > > # time the actual copy > time (....; sync) > well i have tried cp after following above steps then the oputput is as follows [r...@fscops Memcopy]# time cp /test_256.db /mnt real 0m22.474s user 0m0.016s sys 0m1.501s > Greg > -- > Greg Freemyer > Head of EDD Tape Extraction and Processing team > Litigation Triage Solutions Specialist > http://www.linkedin.com/in/gregfreemyer > First 99 Days Litigation White Paper - > http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf > > The Norcross Group > The Intersection of Evidence & Technology > http://www.norcrossgroup.com > -- >From : Vineet Agarwal -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
