![]() | |||||||||||||
Messages in this thread |
Rik van Riel wrote: > On Fri, 27 Feb 2004, Paolo Ornati wrote: > > >>trying to burn a CD "on the fly" I have noticed a strange thing. During the >>burning "iowait" remains enough low (~3%, MAX 10%) but, after a little >>time, it suddenly and quickly goes up to 80-90%: in this condition MKFS >>seems unable to fill the FIFO buffer as quickly as the CD-writer writes > > >>Any ideas? > > > At that point, mkisofs is probably running into a bazillion > small files, in subdirectories all over the place. > > Because a disk seek + track read takes 10ms, it's simply not > possible to read more than maybe 100 of these small files a > second, so mkisofs can't keep up. I certainly have seen this, although there is something odd in the process with large files as well. I sometimes see it in 2.4 as well, so it may be a characteristic of the application. What to do about it (things to try, not requirements): - use fs= to increase the size of the fifo a bit, remember to put "m" after the buffer size or it will be taken in bytes. This helps with the problem Rik describes - be sure DMA is on the CD and the drive - allow ints during io - I'm told deadline schedular but haven't tried it - get a new version of cdrecord, build with the 2.6 headers, use ATAPI:/dev/hdX for dev= instead of ide-scsi (this is probably not critical for data CD in 2.6.2 and later, ide-scsi seems to work) - use burn-free - drop the speed of the burn - build the ISO image first, burn from that instead of a pipe - use growisofs for DVD -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||