Re: [ext2/ext3] Re-allocation of blocks for an inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hello Greg,

sorry i didn't followed it right

Now it's done. this is the output..

[root@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 <greg.freemyer@xxxxxxxxx> wrote:
> On Sat, Mar 14, 2009 at 9:39 AM, Vineet Agarwal
> <checkout.vineet@xxxxxxxxx> wrote:
>> On Fri, Mar 13, 2009 at 9:43 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
>>> On Fri, Mar 13, 2009 at 11:58 AM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote:
>>>> On Fri, Mar 13, 2009 at 9:19 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
>>>>> On Fri, Mar 13, 2009 at 11:23 AM, Vineet Agarwal
>>>>> <checkout.vineet@xxxxxxxxx> 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.
>>>>>>
>>>>>> [root@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
>>
>>  [root@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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux