Re: lseek and write question
On Nov 16, 9:45 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
I am going to ask a question regarding
write and lseek. I will provide code at the end of this, but first
What I found during the test is that fsync is an expensive operation
and will block waiting for a confirmation from the disk device. What
I am trying to understand is the lseek function.
From what I read, it simply moves the pointer in the file descriptor
as directed. When I use this lseek function, writes are faster.
My question is why? When I use the write command, does the pointer
get reset and on each write, it will search for EOF?
This is running Linux sytem.
First a nit pick: 'write' is not a command. It's a function. IIRC,
it's a POSIX function, which isn't really on topic here. Now that's
out of the way, second, in C++ we'd use the 'fwrite' function (from
the C Standard Library). Have you tried switching to using 'fwrite'
It won't work. He's using a functionality (synchronized
writing) which isn't available in the standard library. The
most you can ever guarantee with the standard library (either
FILE* or iostream) is that the data has been transfered to the
OS; his call to fsych guarantees that it has been physically
written on the medium.
And the last point: you might want to consider asking in the Linux
newsgroup since I/O performance depends greatly on the platform, and
there is no real explanation from the language point of view why
'write' is so slow without 'lseek'.
With regards to his particular question, the answer seems
obvious (and will probably be the same on any system, anytime he
doesn't use synchronized writes): because of the seek, he's
always writing the data at the same place on the disk, which
means that the system can always reuse the same sector cache,
and never has to go to disk. Without the seek, he's writing a
fairly large file, and the system probably won't keep all of the
cached data around, but will write to disk.
Is it really surprising that writing a file with one record is
significantly faster than writing one with ops records (where
ops is probably fairly large)?
James Kanze (GABI Software) email:firstname.lastname@example.org
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34