But don't we need the whole area to be zero filled?
On Mar 28, 2009, at 5:02 PM, George Bosilca wrote:
It is way to expensive to write the whole file. That's why I proposed to only write the last byte. This will force the OS to really map the file on the systems less POSIX compliant. george. On Mar 28, 2009, at 13:50 , Jeff Squyres wrote: > How about just write()ing a bunch of 0's instead of using ftruncate? > > On Mar 27, 2009, at 11:09 PM, Eugene Loh wrote: > >> Paul H. Hargrove wrote: >> >> > Quoting from a different manpage for ftruncate: >> > [T]he POSIX standard allows two behaviours for ftruncate >> > when length exceeds the file length [...]: either >> returning an >> > error, or >> > extending the file. >> > So, if that is to be trusted, it is not legal by POSIX to >> *silently* >> > not extend the file. >> >> On a Solaris system, the ftruncate man page says: >> >> truncate, ftruncate - set a file to a specified length >> >> The truncate() function causes the regular file named by >> path to have a size equal to length bytes. >> >> If the file previously was larger than length, the extra >> data is discarded. If the file was previously shorter than >> length, its size is increased, and the extended area appears >> as if it were zero-filled. >> >> So, the sense is not of "truncating" (shortening) per se, but of >> fixing >> a new length, whether that length is longer or shorter. >> >> I guess we could try to track down the ftruncate behavior on the >> systems >> in question, but (IMHO) this doesn't feel like the correct >> explanation. >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel _______________________________________________ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
-- Jeff Squyres Cisco Systems
