>From: James Pearson <[EMAIL PROTECTED]>
>>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 ...
Right, The size depends on many things (RR, Joliet, ...).
It even depends on things such as: do wwe need an extra sector in this
directory due to rounding...
>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 ...
Every modern OS will do this.
Indeed this is where you find the difference in OS quality.
Star has no problems to estimate the size of a 15 GB partition (150000 files)
in about one minute if the fs/disk is fast, so a DVD-R sized tree should
be checked in ~ 12 seconds.
Mkisofs uses much more memory that star and is 50% slower.
Anyway, I expect a 20000 file check to be ready in less than a minute even if
the FS is slow.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
