[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free s

From: Greg Forte
Subject: Re: [Bug-xorriso] xorriso : FAILURE : Image size 2244690s exceeds free space on media -2036700157s
Date: Thu, 18 Aug 2011 22:20:57 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11

hmmmm .. afraid I spoke too soon. a few trial runs worked, but when I put my build system back to normal using the new binary I compiled, I started getting this:

libisofs: FATAL : Cannot convert name '.catalog' to ASCII
libisofs: FATAL : Memory allocation error
xorriso : FAILURE : Failed to prepare session write run
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FATAL

Which seemed very strange since it ran fine for me on the same system. After poking around a lot I've found that the contents of the source dir seems to affect it - the difference between the working run and the broken ones was one file. I thought it might have something to do with clearcase (the "one file" in question was a view private object mixed in with some other stuff), but I can reproduce in a plain old directory, too. It's also not specific to .catalog, which is being generated by the -c mkisofs-style option - if I drop that option, it'll hit the same error on some other file in the source dir. It also doesn't appear to be dependent on where I'm sending the output. It doesn't do it on linux, only Solaris (sparc), at least for the same source directory.


On 08/18/2011 02:46 PM, Greg Forte wrote:
works great - thanks very much!


On 08/17/2011 02:18 AM, Thomas Schmitt wrote:

I think the subject pretty much says it - I'm trying to write out to
a very
large disk array with ~4.5TB of free space. I'm guessing this is a
int wraparound problem,

Looks much like that.
I assume you experience this on Linux. In this case the number of bytes
is read 64 bit from statvfs(2). The number is then stored as 64 bit.
Before writing it is divided by 2048 and stuffed into a signed 32 bit
integer, which then is compared against the predicted image size.

are there any switches to skip the free space check
or otherwise get me past this?

You may hide the target by writing to a pipe.

xorriso -outdev - ... | cat>target_image.iso

But this will only work for single session or with explicitely obtained
Next-Writable-Address numbers as is tradition with mkisofs+cdrecord.

I am currently exploring how to deal better with such a size.
(Will have to fake 4.5 TB of capacity as my disk is only 500 GB.)
As soon as i have a test candidate, i will upload a development tarball
of GNU xorriso and ask you to try it.

One brute-force candidate would be to curb media capacities to 2 TB -
2 kB
already when they are read from the system.
If you have the source code of your xorriso at hand, you may try this
code change:

--- xorriso-1.1.4/libburn/sg-linux.c 2011-07-07 13:50:04.000000000 +0200
+++ xorriso-1.1.5/libburn/sg-linux.c 2011-08-17 08:08:36.000000000 +0200
@@ -1929,6 +1929,8 @@ int burn_os_stdio_capacity(char *path, o
*bytes = add_size + ((off_t) vfsbuf.f_frsize) *
(off_t) vfsbuf.f_bavail;
+ if (*bytes / (off_t) 2048> (off_t) 0x7fffffff)
+ *bytes = ((off_t) 0x7fffffff) * (off_t) 2048;
ret = 1;

It would be interesting to know whether this shows any inconsistencies
with your disk array.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]