Re: tuning for large files in xfs

[Avi Kivity <avi@argo.co.il>]

fitzboy wrote:
> Avi Kivity wrote:
> > This will overflow. I think that
>
> 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...

You're right, of course.  Thinko on my part.

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

I presume that was with the 20GB file?

If so, that rules out the filesystem as the cause.

I would do the following next:

- run the test on the device node (/dev/something), just to make sure. 
you will need to issue an ioctl (BLKGETSIZE64) to get the size as fstat 
will not return the correct size
- break out the array into individual disks and run the test on each 
disk.  that will show whether the controller is causing the problem or 
one of the disks (is it possible the array is in degraded mode?)

--
error compiling committee.c: too many arguments to function

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