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

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

 



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
>>>
>>
>> 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.
>>
>> 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)

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

--
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