hello Greg, sorry i didn't followed it right
Now it's done. this is the output.. [r...@fscops Memcopy]# time (cp /test_256.db /mnt; sync) real 0m24.039s user 0m0.022s sys 0m1.566s On Sat, Mar 14, 2009 at 10:13 PM, Greg Freemyer <[email protected]> wrote: > On Sat, Mar 14, 2009 at 9:39 AM, Vineet Agarwal > <[email protected]> wrote: >> 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 >> > > I still don't see a concluding sync. It is mandatory and it has to be > within the parens. > > ie. > time (cp /test_256.db /mnt; sync) > > 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
