fread split in many read

[Nicolas Boulay]

2007/1/22, Kaz Kylheku <kaz@zeugmasystems.com>:
>  Nicolas Boulay wrote:
> > Hello,
> >
> > I use strace on some program. And i could see that most of the time,
> > the transfert get fragmented using 4K paquets.
>
> You are using C streams (FILE *), which are buffered by default on
> non-interactive devices. The default buffer size in glibc is 4096 bytes.
> Streams are designed to efficiently support a mixture of variable length
> transfer operations using functions like getc and putc, fread and write,
> and fgets and fputs.
>

But why not asking directly the size requested ? Why using a buffer to
recopy one more time the data ?

Nevertheless, 64K as a default buffer size enable be much faster
access for a lot of software.

> > Bloc layer are design to concatenate consecutive access. So why
> > fragment to then defragement. Anticipatory scheduler wait for new read
> > demand, i understood why it's so efficent if each fread are split.
>
> Use read and write if you want to control the I/O transfer unit sizes,
> and do I/O in large blocks.
> You can tune the stream buffer size too.  Read up on setvbuf.
>

Yes, but changing libc speed up everything.

> > I don't check a lot the fwrite part, but i still see 4K write . Some
> > file system tend to be atomic on write to avoid trashing file. So
> > spliting write, destroy this feature.
>
> A large write by itself does not guarantee atomicity. Atomic supersedes
> require special logic in the filesystem.

I know. Reiserfs clams to do that.

> You can emulate atomic
> supersede using the rename() operation: prepare a new version of the
> file under a temporary name, and then move it over top of the old one.
> You also need a recovery procedure in place that removes the temporary
> files after a crash.
>
>