How to interrogate optical discs

Robert G. (Doc) Savage dsavage at peaknet.net
Tue Jun 15 22:07:13 UTC 2010


On Tue, 2010-06-15 at 17:07 -0400, Tom Horsley wrote:
> On Tue, 15 Jun 2010 14:37:14 -0500
> Robert G. (Doc) Savage wrote:
> 
> > I believe it's either an
> > error in the file size sorting algorithm, or some extra data being added
> > to the ISO image.
> 
> I'm pretty sure there is an indeterminate amount of overhead
> added for the table of contents, storage layout info, etc.
> You can't tell how much will be used till you actually make an
> image an see how big it is.

Tom,

I hope you've been following this thread. The objective of discspan.py
is to archive the contents of a directory onto a spanned set of DVD
discs. It does this by sorting the contents into an optimal set of
buckets that will each fit on a chosen disc type, using growisofs to
build ISOs out of each bucket, then burn each ISO in turn to a series of
discs. No files are split.

I've been using discspan.py to archive the contents of my Fedora
mirror's /pub/fedora/linux/releases/13/Everything directory, whose files
range in size from 1K to over 800M. Richard Shaw has used it to archive
pictures. Both of us want to keep the individual files individually
accessible on the discs, which pretty much rules out other tools like
tar.

The most recent discspan.py uses /etc/discspan.ini to store static
information about DVD formats. For example:
...
dvd_plus_r = 4.38G
...

If you use that max size value (computed from 2,295,104 * 2K blocks) and
you have a file list whose sizes add up to 4.38G, an overflow will
result. To avoid that, I reduced that entry from 4.38G to 4.365G. My
solution is obviously a kluge.

If there really is overhead and other data being added, we'd like to
know as accurately as possible the size of that added amount.

--Doc



More information about the users mailing list