>If the best guess technique is used that means almost >all the discs would not be filled to capacity. The >data be burned is being kept online via Pioneer >jukeboxes in our data center (700 discs each). Thus >the idea of not filling each disc to its full capacity >means we are not maximizing our use of square footage >in the data center, we are not using the full capacity >of the jukeboxes and the media. While this would >improve performance it would waste lots of precious >money. This is why I opted to go with the slow >technique instead of best guess. I appreciate the >suggestion. > >I guess the perfect world solution would be to have >some option for mkisofs -print-size to store its run >information and to have another option to add a >file(s) to its previous run. That way the problem >could be called sort of incrementally without >re-reading all the old files again. On CD-R this isn't >too bad but we do a lot of DVD-R stuff too. The DVD-Rs >are holding 17,000 to 21,000 files per disc, thats a >lot of files to re-read each time! To help with this I >am getting a SCSI hard drive.
I guess it would be difficult to modify (or re-write) mkisofs to do what you want - but not impossible ... When -print-size option is used, no file data is read - athough every file is stat'ed, so the best thing to do is to make sure your OS can cache that amount of inode data in memory ... James Pearson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
