Message-ID: <44736EBE.3030704@iparadigms.com>
Date: Tue, 23 May 2006 13:21:18 -0700
From: fitzboy <fitzboy@iparadigms.com>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041124)
MIME-Version: 1.0
To: Avi Kivity <avi@argo.co.il>
CC: linux-kernel@vger.kernel.org
Subject: Re: tuning for large files in xfs
References: <447209A8.2040704@iparadigms.com> <44720DB8.4060200@argo.co.il> <447211E1.7080207@iparadigms.com> <447212B5.1010208@argo.co.il> <447259E7.8050706@iparadigms.com> <4472C25C.2090909@argo.co.il>
In-Reply-To: <4472C25C.2090909@argo.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1304
Lines: 35


Avi Kivity wrote:
> 
> This will overflow. I think that
> 
>      currentPos = drand48() * s.st_size;
> 
> will give better results
> 
>>     currentPos=currentPos%s.st_size;
> 

why would it overflow? Random() returns a 32 bit number, and if I 
multiple that by 32k (basically the number random() returns is the block 
number I am going to), that should never be over 64 bits? It may be over 
to size of the file though, but that is why I do mod s.st_size... and a 
random number mod something is still a random number. Also, with this 
method it is already currentSize aligned...

> 
> Sorry, I wasn't specific enough: please run iostat -x /dev/whatever 1 
> and look at the 'r/s' (reads per second) field. If that agrees with what 
> your test says, you have a block layer or lower problem, otherwise it's 
> a filesystem problem.
> 

I ran it and found an r/s at 165, which basically corresponds to my 6 ms 
access time... when it should be around 3.5ms... so it seems like the 
seeks themselves are taking along time, NOT that I am doing extra seeks...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/