Re[4]: Filesystem overhead?
Hello, MFM Since DVD-Rs have UDF (extensions?|Along with ISO9660?) on them MFM as well, I'm assuming their overhead would be slightly greater as MFM well, correct? One should note that there are more and more DVDs without the UDF file system. In particular, all newer DVDs sent by Microsoft to the MSDN subscribers only have an ISO filesystem. Lac I was under the impression that UDF was designed to be able to accept Lac adding of files subsequent to the initial writing. Certainly that is Lac not required for the MSDN application. All DVD-ROMs I got in the past had a double filesystem: ISO and UDF. I think this was the rule till now. I don't remember exactly where this is specified. Recently, while looking at MSDN DVD-ROMs (it is true for all 2002 disks), I observed that the ISO filesystem was the only one on the disk. -- Best Regards Pierre Duhem Logiciels Services Duhem, Paris (France) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re[2]: Filesystem overhead?
[EMAIL PROTECTED] quoted and then wrote: From: [EMAIL PROTECTED] (Pierre Duhem) Reply-to: [EMAIL PROTECTED] (Pierre Duhem) To:[EMAIL PROTECTED], [EMAIL PROTECTED] (Mike Fox Morrey) Mike, MFM Since DVD-Rs have UDF (extensions?|Along with ISO9660?) on them MFM as well, I'm assuming their overhead would be slightly greater as MFM well, correct? One should note that there are more and more DVDs without the UDF file system. In particular, all newer DVDs sent by Microsoft to the MSDN subscribers only have an ISO filesystem. I was under the impression that UDF was designed to be able to accept adding of files subsequent to the initial writing. Certainly that is not required for the MSDN application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filesystem overhead?
From: Mike Fox Morrey [EMAIL PROTECTED] This is definitely the best solution: Check for the overhead for your typical case. If you put 2 files on the disk, it should be easy to find a solition that does not waste more than 5% of the media size. Good idea - something I'll start tackling once I finish the latest update to my program. Since DVD-Rs have UDF (extensions?|Along with ISO9660?) on them as well, I'm assuming their overhead would be slightly greater as well, correct? With my tests, using a 18 GB FS and an average filesize of 154 kB, I got an overhead of 2% for adding UDF. 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 Jorg 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]
Re[2]: Filesystem overhead?
Mike, MFM Since DVD-Rs have UDF (extensions?|Along with ISO9660?) on them MFM as well, I'm assuming their overhead would be slightly greater as MFM well, correct? One should note that there are more and more DVDs without the UDF file system. In particular, all newer DVDs sent by Microsoft to the MSDN subscribers only have an ISO filesystem. -- Best Regards Pierre Duhem Logiciels Services Duhem, Paris (France) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filesystem overhead?
Hello Mike, MFM Hey guys.. MFM Quick technical question... MFM I was under the impression that the size that a filesystem took on the MFM disk varied, depending on the files/direcory structure, but am now starting MFM to believe this is incorrect. MFM On a standard ISO9660 disk, is the filesystem static in size, or does it vary? It varies, of course, depending on the number of entries it has to contain. But there is also a minimal size (16 empty sectors, volume descriptor, path tables, roo directory). That is, the overhead for a disk with 1 file and for say 15 files is the same. -- Best Regards Pierre Duhem Logiciels Services Duhem, Paris (France) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filesystem overhead?
I have the same problem. My system is automatically receiving files over the network and archiving them to CD-R. I wanted a way to automatically determine in my own program when the CD-R would be full when selecting files to be put on the CD-R. For this to be accurate you need to know the filesystem overhead (as you clearly state). I tried looking at the mkisofs code to figure this out but it was more complicated than I was willing to do so instead I used the command mkisofs -print-size DIR to determine how big an ISO of that directory would be. I then compare it to my disc size, if there is more room I add another file. I do this in my program after each file I select to put on the CD-R to make sure I don't overrun the media size. This is terribly inefficent but I don't know what else to do. To help minimize the number of calls to -print-size I changed my program so I only call it after the size of the files equals 90%+ of the media size (only do accurate size check when rough size check is getting close to full). It is still slow but tolerable. Any other suggestions would be appreciated. --- Pierre Duhem [EMAIL PROTECTED] wrote: Hello Mike, MFM Hey guys.. MFM Quick technical question... MFM I was under the impression that the size that a filesystem took on the MFM disk varied, depending on the files/direcory structure, but am now starting MFM to believe this is incorrect. MFM On a standard ISO9660 disk, is the filesystem static in size, or does it vary? It varies, of course, depending on the number of entries it has to contain. But there is also a minimal size (16 empty sectors, volume descriptor, path tables, roo directory). That is, the overhead for a disk with 1 file and for say 15 files is the same. -- Best Regards Pierre Duhem Logiciels Services Duhem, Paris (France) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filesystem overhead?
I have the same problem. My system is automatically receiving files over the network and archiving them to CD-R. I wanted a way to automatically determine in my own program when the CD-R would be full when selecting files to be put on the CD-R. For this to be accurate you need to know the filesystem overhead (as you clearly state). I tried looking at the mkisofs code to figure this out but it was more complicated than I was willing to do so instead I used the command mkisofs -print-size DIR to determine how big an ISO of that directory would be. I then compare it to my disc size, if there is more room I add another file. I do this in my program after each file I select to put on the CD-R to make sure I don't overrun the media size. This is terribly inefficent but I don't know what else to do. To help minimize the number of calls to -print-size I changed my program so I only call it after the size of the files equals 90%+ of the media size (only do accurate size check when rough size check is getting close to full). It is still slow but tolerable. Any other suggestions would be appreciated. This question comes up from the time to time There is no easy way to accurately estimate the overhead - except by running mkisofs with the -print-size option All I would suggest is using a 'safe' overhead percentage based on CDs you've already written. James Pearson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filesystem overhead?
From [EMAIL PROTECTED] Tue Jun 25 17:35:15 2002 The waste of space due to rounding can be avoided using the patch attached. Eduardo Pérez --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mkisofs_notevenpathtables.diff --- cdrtools-1.10/mkisofs/mkisofs.cTue Dec 11 21:39:45 2001 +++ cdrtools-1.10/mkisofs/mkisofs.cTue Dec 11 21:39:56 2001 @@ -2735,14 +2735,8 @@ } /* Now assign addresses on the disc for the path table. */ - path_blocks = (path_table_size + (SECTOR_SIZE - 1)) 11; - if (path_blocks 1) - path_blocks++; - This is unrelated to to the problem ISO-9660 requires directory entries not to span sector limits. 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 Jorg 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]
Re: Filesystem overhead?
From: Mike Fox Morrey [EMAIL PROTECTED] Now, I can run the -print-size option, but that causes (for me) unneccessary overhead and gives: 1. The OS/mkisofs to cause an error and abort the automated burn, and/or 2. The user to intr it or susp it or otherwise 'get in the way', which I also want to avoid. (And, considering the way I'm running it (combined C code with Informix FGL language), calling external commands are slower than molasses in January.. Since (and I mean this in the gentlest way possible) 99% of my clients are monkey-brains, I don't think they'll notice that the discs aren't 100% full. : This is definitely the best solution: Check for the overhead for your typical case. If you put 2 files on the disk, it should be easy to find a solition that does not waste more than 5% of the media size. 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 Jorg 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]
Re: Filesystem overhead?
This is definitely the best solution: Check for the overhead for your typical case. If you put 2 files on the disk, it should be easy to find a solition that does not waste more than 5% of the media size. Good idea - something I'll start tackling once I finish the latest update to my program. Since DVD-Rs have UDF (extensions?|Along with ISO9660?) on them as well, I'm assuming their overhead would be slightly greater as well, correct? Mike.. --- Mike 'Fox' Morrey - Noble Systems Support - Friends don't let Friends drive Naked. - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Filesystem overhead?
Hey guys.. Quick technical question... I was under the impression that the size that a filesystem took on the disk varied, depending on the files/direcory structure, but am now starting to believe this is incorrect. On a standard ISO9660 disk, is the filesystem static in size, or does it vary? Thanks! Mike. --- Mike 'Fox' Morrey - Noble Systems Support - If We Quit Voting, Will They All Go Away? - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
