On Sat, 2006-11-11 at 20:35 -0500, Kevin J. Cummings wrote: > Hi Folks, > I have a backup of my system in an "exustar" .star archive file. Its > 7.5 GB in size. I want to write this file to a Double Layer DVD+R disk > which claims to be 8.5GB in capacity. I have tried growisofs, and K3B, > and I can't seem to find the magic incantation which will allow me to do > this: > > > growisofs -dvd-compat -dry-run -speed=2 -Z /dev/hdd root.star > > Executing 'mkisofs root.star | builtin_dd of=/dev/hdd obs=32k seek=0' > > INFO: ISO-8859-1 character encoding detected by locale settings. > > Assuming ISO-8859-1 encoded filenames on source filesystem, > > use -input-charset to override. > > mkisofs: Value too large for defined data type. File root.star is too large - ignoring I think your problem is in the mkisofs step. I'm not seeing anything in the mkisofs documentation explicitly indicating that it supports creation of dual-layer iso images. You can ask around on the cdrtools mailing lists. You can also check the mkisofs source code; look for any sort of constants or #defines that may relate to DVD_MAX_IMAGE_SIZE (or whatever), and then look for any "if" conditional statements that would exit with an error status if image_file_size > DVD_MAX_IMAGE_SIZE, for example. You could then add a constant to handle the larger media type input data size, and modify the conditionals accordingly. Maybe even add a command-line option to explicitly tell mkisofs that it will be generating an iso image for dual-layer dvd media, so it can expect and size accordingly. > > Total translation table size: 0 > > Total rockridge attributes bytes: 0 > > Total directory bytes: 0 > > Path table size(bytes): 10 > > With K3B, when I try and move the root.star file into the DVD Project > window (after making it 8.0GB in size), I get a popup telling me that > K3B can't move files bigger than 4GB! I rarely use k3b, myself. Looks like k3b isn't dual-layer aware yet? Once again, check the mailing lists, documentation, and/or the source. > > Is this a limitation of the DL format? single files can't span the layers? I could be wrong, but i think the dual-layer devices provide a sufficient layer of abstraction to handle the storage implementation details, such that this would not be an issue. > > I've read the "Blu-ray Disc/DVD+RW/+R/-R[W] for Linux" document by > <appro@xxxxxxxxxxxxxx>, and the only thing I can find on the subject says: > > > # And when it comes to DVD+R Double Layer and DVD-R Dual Layer recordings, > > growisofs applies yet another limitation, purely artificial. Taking > > into consideration Double Layer media prices growisofs is programmed to > > refuse to perform unappendable recordings which are less than 1/2 of > > blank capacity and to advice to use single layer media instead. > > Well, what I saw was growisofs very nicely eliminated the 7.5GB file and > burned me an empty fs. B^( > > Using the -overburn option doesn't seem to help with growisofs. > > I also tried with nautilus-cd-burner. I was able to move the 7.5GB file > into my session, but the attempt to burn it errored out with: > > > An unknown error occured while writing to the DVD" > > I even tried writing directly to an image.iso file with > nautilus-cd-burner, but the resulting image.iso contains an empty > filesystem (and is only 370688 bytes in size!) and doesn't produce any > visible error messages. > > What's my solution? > > What am I missing? > > Do I need to break my single 7.5GB file into 2 smaller files in order to > burn them onto the DL DVD+R? That, or do what i did, and get yourself a large external usb storage device, and use that to backup your stuff :p > > Why isn't there a HOWTO that talks about the details of burning a > DL-DVD+R and the practical limitations? (Most of what I've found > pertains primarily to Video DVDs, and while they are both technically > Data-DVDs, there are practical differences, as I want to burn a single > large file into my filesystem....) There may yet be, somewhere. But if there absolutely is not, it's probably because nobody has gotten around to it or been paid to do it yet. However, once you've got this all figured out, if you'd be so kind as to create documentation or submit proposed documentation enhancements to interested maintainers, i'm sure the next poor soul who runs into this type of situation will be eternally grateful to you :). > > All help appreciated! > > -- > Kevin J. Cummings > kjchome@xxxxxxx > cummings@xxxxxxxxxxxxxxxxxx > cummings@xxxxxxxxxxxxxxxxxxxxxxx > Registered Linux User #1232 (http://counter.li.org)
