Paul Davis <[EMAIL PROTECTED]> writes: >>That's discouraging about reiserfs. Is it version 3 or 4? Earlier >>versions showed good realtime responsiveness for audio testers. It >>had a reputation for working much better at lower latency than ext3. > > over on #ardour last week, we saw appalling performance from > reiserfs. a 120GB filesystem with 11GB of space failed to be able to > deliver enough read/write speed to keep up with a 16 track > session. When the filesystem was cleared to provide 36GB of space, > things improved. The actual recording takes place using writes of > 256kB, and no more than a few hundred MB was being written during the > failed tests. > > everything i read about reiser suggests it is unsuitable for audio > work: it is optimized around the common case of filesystems with many > small files. the filesystems where we record audio is typically filled > with a relatively small number of very, very large files.
I was not speaking of its disk performance, but rather of low-latency CPU performance. In 2.4 with the low-latency patches, reiserfs did that fairly well. I know its design is not focused on streaming large blocks of data to disk. But, when you're recording clicks every 20 seconds, disk throughput is definitely a secondary consideration. Looks like we need to do another study to determine which filesystem works best for multi-track audio recording and playback. XFS looks promising, but only if they get the latency right. Any experience with that? -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
