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? > > 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. Here is a link to ext4 defrag design. www.kernel.org/doc/ols/2007/ols2007v2-pages-179-186.pdf Thanks - Manish > > 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
