Hi Greg, On Sat, Jan 17, 2009 at 4:34 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > <snip> >>>> But, first I will see the performance metrics of dividing the copy >>>> operation in some chunks. >>>> >>> Agreed. >>> >>> Somewhere I think I read you were doing 1 GB in less than a second or >>> something like that. >>> >>> Am I remembering right? >>> >> Yes that is true. The approx figure for 512M file was 230 milliseconds. >> The code is currently in testing phase so we will let you know >> the exact figures. >> > > Suspiciously fast. At first glance I don't trust your benchmarking > methodology. Or are you using a ramdisk for both of your tiers? > Yes thats right. The data was not being synced to disk. We are using SATA and SSD's for out testing purposes. Can you suggest us what kind of benchmarking should we follow ? I mean we should compare our performance with other similar utilities and not with the standard I/O timings. > If it is real disk, I suspect you are not getting that data to the > disk in that timeframe, just setting up you write queues. > Exactly, this was the reason. > Trouble is that you then release the lock, which means the buffers are > subject to overwriting. > > If I am right, you 2 choices to preserve the integrity of the data: > > 1) Ensure the write queue gets flushed before you release the lock. > (Anyone know how to do this in the kernel itself? Should just be a > matter of tracing a fsync call().) > > 2) Institute the memcpy() call such that you don't rely on the data > getting to disk prior to releasing the lock. > Not seeing much time difference as of now. The reason probably being even a memcpy is a in-memory operation. I know I have kept all curious for some time and should provide the basic code framework. We will do it soon.... We got some issues and Manish has been helping us to come out of that issue from last couple of days. We are almost out of it. > If you decide to go route 2), you will likely still need to flush/sync > your queues as part of the benchmarking process, so you need to know > how to do that either way. > Help us with the benchmarking ? > Greg > -- > Greg Freemyer > 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 > -- Regards, Sandeep. "To learn is to change. Education is a process that changes the learner." -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
