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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
