Re: dvd+rw-tools-5.20.4.10.8: File is too large
me > > Therefore the constraints with my advice to write the tar.gz file
> > to DVD without an ISO wrap. That would be readable on any Unix.
Helmut Jarausch > Yes and No,
> Since there is no notion of a file length and most of the time
> I get LOTS of errors and the end of the file when reading from a
> raw CD.
But tar knows when it reaches the end of an archive. So the file
length is not really in question.
You describe the annoying read-ahead bug which is not specific to the
data format but to CD reading on Linux. (I do not experience
it with growisofs written DVD+RW on Linux)
The workaround is to add some padding. cdrecord option padsize=128k
seems to be enough for even the most eager read-aheaders.
One usually does not experience trouble with ISO filesystems on CD
because mkisofs adds a generous amount of padding by default.
(300 kB according to 2.01a35's man mkisofs, option "-pad")
me > >
> > I cannot imagine a method to mix on-the-fly file parts
> > with usual mkisofs input from disk directories. Or to fiddle
> > disk directories into something like -stream-media-size :(
>
Helmut Jarausch >
> What's the problem?
> If both parts reside on the same volume (DVD)
> e.g. as B.tar.gz.1 B.tar.gz.2
> cat /dvd/B.tar.gz.1 /dvd/B.tar.gz.2 | tar xzf -
The problem is about writing pieces of large files. Not about putting
them together.
With my ISO backups there is no intermediate archive format.
The files are randomly accessible on the media with any computer
system which knows about ISO.
Put in the media and click on files - that's how the Windows users
want it. Admins of Samba servers show their loving care to their
clients by handing over personal backups or emergency DVDs for
the case that the server is down.
For a Linux user it is still a fine feature to work with usual
programs directly on CD rather than having to extract files from
a backup archive to hard disk.
My technical problem :
With mkisofs i know the traditional way to give addresses of
files or directories existing on the hard disk as input (pathspec).
There also is a stream input mode which produces an ISO image
containing a single file (-stream-media-size).
Paul Serice's flyisofs can produce several files (in a single
directory, using something like multi-session chaining, if i got
it right). But this is not suitable for tens of thousands of single
files. It would be a very unusual ISO image layout (including the
4 GB inode problem on older Linux) and i guess there would be other
drawbacks.
None of these models suits my dream. I read and squeeze man mkisofs
in the hope to find a hint for a solution - no success up to now.
Joerg: i would love to get an RTFM if there is any way to construct
a mkisofs pathspec that does not describe the whole file but only
a specified piece of it.
Have a nice day :)
Thomas
Reply to: