[OpenAFS-devel] dumpstuff.c buffering: 2 questions

[Jeffrey Hutzelman]

On Tuesday, November 15, 2005 03:49:46 PM +0100 Peter Somogyi 
<psomogyi@gamax.hu> wrote:

> I've examined FDH_READ implementation, it's a standard read.
> I've read its manual (man 2 read), and it tells "[...]it is not an error
> if this number is smaller than the number of bytes requested; this may
> happen        for example because fewer bytes are actually available
> right now (maybe because we were close to end-of-file,  or        because
> we  are  reading  from  a  pipe, or from a terminal)[...]". So I think
> instead of null padding it should continue reading (if n>0, of course) -
> at least on Linux platform. Am I right?

The documentation of read(2) tends to be a little bit abstract.  Access to 
plain files is "fast"; there is no possibility of blocking or getting a 
short read because there is more data coming that hasn't arrived yet.  You 
can get a short read if you hit EOF, but the files that DumpFile() are 
reading are of known size, so a short read means there was a real error, 
either during the read or (more likely) because the contents of the disk 
aren't what they're supposed to be.  There's never going to be more data. 
It becomes necessary to pad the output buffer because the dump tag which 
indicates how many bytes are coming has already been sent, and so we have 
to fulfill that requirement or they won't be able to process the rest of 
the dump.



> Another question is about rx_Write(call, buf, nbytes): is it true that
> writting less (but >0) than nbytes means an error? (in case of file
> write: it's also not an error)

write(2) is very similar to read(2) in this respect.  A short write on a 
plain file always indicates a problem; you really only need to be able to 
deal with short writes on "slow" file descriptiors like devices, pipes, or 
sockets.

In any case, rx_Write is not write(2).  It's a little hard to tell without 
carefully analyzing the code, but rx_Write will never return a short write; 
it will always return either the full number of bytes written or zero, with 
the latter indicating an error.


-- Jeff