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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
