<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? 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. 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. 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. 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 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
