On 10/22/2013 05:56 PM, Gabriel de Perthuis wrote:
---
pxzcat.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pxzcat.c b/pxzcat.c
index 4ab8689..9bcdc36 100644
--- a/pxzcat.c
+++ b/pxzcat.c
@@ -29,10 +29,11 @@
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
+#define _GNU_SOURCE
#include <config.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
@@ -166,12 +167,12 @@ xzfile_uncompress (const char *filename, const
char *outputfile,
debug ("uncompressed size = %" PRIu64 " bytes", size);
ofd = open (outputfile, O_WRONLY|O_CREAT|O_TRUNC|O_NOCTTY, 0644);
if (ofd == -1)
error (EXIT_FAILURE, errno, "open: %s", outputfile);
- if (ftruncate (ofd, size) == -1)
- error (EXIT_FAILURE, errno, "ftruncate: %s", outputfile);
+ if (fallocate (ofd, 0, 0, size) == -1)
+ error (EXIT_FAILURE, errno, "fallocate: %s", outputfile);
Why exit here.
Maybe just warn and fall back to truncate, for ENOSYS or ENOTSUP
as the (file) system may not support this operation.
Also this adds an upfront space reservation,
which could be seen as a benefit to exit early
if we would not have enough space for the operation,
but also problematic if we don't actually need that
space due to sparseness. Do we get prior knowledge
of the sparseness to be able to fallocate() and appropriate amount?
/* Tell the kernel we won't read the output file. */
posix_fadvise (fd, 0, 0, POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED);
I know this isn't related to your patch,
but I don't think you can set a flag like this.
These are rather operations that need to be done
while writing I think.
For ref I made the above call after writing various chunks to disk in:
https://github.com/pixelb/dvd-vr/blob/master/dvd-vr.c#L322
and also dd:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=5f31155
BTW dd has this as an option, and dvd-vr is a specialized tool
often handling large files, so in both these cases FADV_DONTNEED
is appropriate. If pxzcat will always be used for virt images then
that does seem appropriate there too, though if used for general
files then probably not.
cheers,
Pádraig.