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]

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.programmer as your code is UNIX
specific and hardly standard C.

[Barry Schwarz]

On Thu, 24 Apr 2008 14:35:35 +0530, santosh <sa*********@gmail.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.programmer as your code is UNIX
specific and hardly standard C.

Remove del for email

[Ian Collins]

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]

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]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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]

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

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

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

>In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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]

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

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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]

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

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@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.