This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: fread split in many read
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.