Random IO Read

[moonhkt]

Hi All

Below coding for generate a file. Do you know how to write a code for
random a a file for multi-user access ?

We want testing FileSystem IO performance.

#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

#define FAIL -1
#define BSIZE 8192
#define FSIZE 5000

int writeit(int);
int main(void)
{
if ( -1 == writeit(FSIZE)) printf("FILE OPERATION FAILED\n");
}

int writeit(int blocks)
{
char buf[BSIZE];
int fdes;
int i;
int written;
if ( (fdes = open("./testfile.bm",O_ WRONLY|O_CREAT, 0777)) < 0)
return FAIL;
for (i=0;i< blocks ; i++)
{
if (written = write(fdes,buf, BSIZE) != BSIZE) return FAIL;
}
return 0;
}

[santosh]

Re: Random IO Read

moonhkt wrote:

Hi All
>
Below coding for generate a file. Do you know how to write a code for
random a a file for multi-user access ?
>
We want testing FileSystem IO performance.
>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
>
#define FAIL -1
#define BSIZE 8192
#define FSIZE 5000
>
int writeit(int);
int main(void)
{
if ( -1 == writeit(FSIZE)) printf("FILE OPERATION FAILED\n");
}
>
int writeit(int blocks)
{
char buf[BSIZE];
int fdes;
int i;
int written;
if ( (fdes = open("./testfile.bm",O_ WRONLY|O_CREAT, 0777)) < 0)
return FAIL;
for (i=0;i< blocks ; i++)
{
if (written = write(fdes,buf, BSIZE) != BSIZE) return FAIL;
}
return 0;
}

You'll be better served in comp.unix.progr ammer as your code is UNIX
specific and hardly standard C.

[Barry Schwarz]

Re: Random IO Read

On Thu, 24 Apr 2008 14:35:35 +0530, santosh <santosh.k83@gm ail.com>
wrote:

>moonhkt wrote:
>

>Hi All
>>
>Below coding for generate a file. Do you know how to write a code for
>random a a file for multi-user access ?

Ignoring your non-standard functions and headers, your problem seems
to be how to fill buf with BSIZE random char. One method would be to:
Change buf to unsigned char.
Call srand to seed the rand function.
In a loop, call rand and store some part of the int it returns in
the "current" element of buf.

>>
>We want testing FileSystem IO performance.

Is it a reasonable concern that IO performance would be affected by
the bit patterns involved? Would the results be any different if buf
were filed with 0xa5? If there is a difference, is 5000 char enough
for it to be noticed (or measured)?

>>
>#include <fcntl.h>
>#include <stdio.h>
>#include <unistd.h>
>>
>#define FAIL -1
>#define BSIZE 8192
>#define FSIZE 5000
>>
>int writeit(int);
>int main(void)
>{
> if ( -1 == writeit(FSIZE)) printf("FILE OPERATION FAILED\n");
>}
>>
>int writeit(int blocks)
>{
> char buf[BSIZE];
> int fdes;
> int i;
> int written;
> if ( (fdes = open("./testfile.bm",O_ WRONLY|O_CREAT, 0777)) < 0)
> return FAIL;
> for (i=0;i< blocks ; i++)
> {
> if (written = write(fdes,buf, BSIZE) != BSIZE) return FAIL;
> }
> return 0;
>}

>
>You'll be better served in comp.unix.progr ammer as your code is UNIX
>specific and hardly standard C.

Remove del for email

[Ian Collins]

Re: Random IO Read

moonhkt wrote:

Hi All
>
Below coding for generate a file. Do you know how to write a code for
random a a file for multi-user access ?
>
We want testing FileSystem IO performance.
>

If you want to do that, use one of the many tools that have been
designed for this task.

--
Ian Collins.

[Antoninus Twink]

Re: Random IO Read

On 24 Apr 2008 at 8:48, moonhkt wrote:

Below coding for generate a file. Do you know how to write a code for
random a a file for multi-user access ?

Why not read /dev/urandom ?

[Walter Roberson]

Re: Random IO Read

In article <slrng11km2.flc .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>On 24 Apr 2008 at 8:48, moonhkt wrote:

>Below coding for generate a file. Do you know how to write a code for
>random a a file for multi-user access ?

>
>Why not read /dev/urandom ?

The OP indicated they wanted to test filesystem IO performance,
not /dev/urandom performance. When implemented at all, /dev/urandom
is not designed for high performance.

/dev/urandom is not even part of POSIX, let alone part of C.

--
"A scientist who cannot prove what he has accomplished,
has accomplished nothing." -- Walter Reisch

[Antoninus Twink]

Re: Random IO Read

On 24 Apr 2008 at 18:52, Walter Roberson wrote:

In article <slrng11km2.flc .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>>Why not read /dev/urandom ?

>
The OP indicated they wanted to test filesystem IO performance,
not /dev/urandom performance. When implemented at all, /dev/urandom
is not designed for high performance.

OK, then why not copy as many bytes from /dev/urandom as desired to a
file, then read that file?

[Walter Roberson]

Re: Random IO Read

In article <slrng11mua.flc .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>On 24 Apr 2008 at 18:52, Walter Roberson wrote:

>In article <slrng11km2.flc .nospam@nospam. invalid>,
>Antoninus Twink <nospam@nospam. invalidwrote:

>>>Why not read /dev/urandom ?

>The OP indicated they wanted to test filesystem IO performance,
>not /dev/urandom performance.

>OK, then why not copy as many bytes from /dev/urandom as desired to a
>file, then read that file?

Because, as I pointed out earlier, /dev/urandom is not part of C
and is not even part of POSIX ?

--
"All human knowledge takes the form of interpretation. "
-- Walter Benjamin

[Antoninus Twink]

Re: Random IO Read

On 24 Apr 2008 at 19:51, Walter Roberson wrote:

In article <slrng11mua.flc .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>>OK, then why not copy as many bytes from /dev/urandom as desired to a
>>file, then read that file?

>
Because, as I pointed out earlier, /dev/urandom is not part of C
and is not even part of POSIX ?

C and POSIX aren't sacred cows - use the best tool for the job. If the
OP's system *does* have /dev/urandom available, then that's a much
better option than reinventing the wheel.

[Walter Roberson]

Re: Random IO Read

In article <slrng11q03.n1s .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>C and POSIX aren't sacred cows - use the best tool for the job. If the
>OP's system *does* have /dev/urandom available, then that's a much
>better option than reinventing the wheel.

If the OP is going to precreate the file and has /dev/urandom
then they very likely have /dev/random as well, which will create a
more random file, thus better testing the throughput limits on
links that have compression enabled. Not that /dev/random is
C or POSIX either, but for the original poster's purpose, /dev/urandom
isn't even the best tool on systems that have it.

For testing throughput limits on links that have compression enabled,
one does not even need true randomness, only sufficiently good
pseudo-randomness, such as using one of the portable implementations
of the Mersenne Twister algorithm.

--
"Do diddle di do,
Poor Jim Jay
Got stuck fast
In Yesterday." -- Walter De La Mare

[Antoninus Twink]

Re: Random IO Read

On 24 Apr 2008 at 20:14, Walter Roberson wrote:

In article <slrng11q03.n1s .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:
>

>>C and POSIX aren't sacred cows - use the best tool for the job. If the
>>OP's system *does* have /dev/urandom available, then that's a much
>>better option than reinventing the wheel.

>
If the OP is going to precreate the file and has /dev/urandom
then they very likely have /dev/random as well, which will create a
more random file, thus better testing the throughput limits on
links that have compression enabled. Not that /dev/random is
C or POSIX either, but for the original poster's purpose, /dev/urandom
isn't even the best tool on systems that have it.
>
For testing throughput limits on links that have compression enabled,
one does not even need true randomness, only sufficiently good
pseudo-randomness, such as using one of the portable implementations
of the Mersenne Twister algorithm.

These two paragraphs seem to contradict each other. He's testing a file
system, so tiny differences in "randomness " are irrelevant - I agree.
Therefore he should use /dev/urandom, rather than waiting around while
/dev/random blocks waiting for more entropy to be generated.