Hi Ted, thanks very much for getting back to me The problem started when I upgraded from Fedora 14 to Fedora 15. Previously I was using ext3. However, I was also using a different firewire stack (the "old stack", instead of the new "Juju stack"). So, there have been several changes around the time that the problem started, not only a change to Ext4. I have tried many different buffer sizes on the audio software. Previously this hardware worked perfectly with 3 * 256 buffers. I've tried up to 3 * 1024 buffers, but I still get the same problem. I tried using barrier=0. This stopped the "writing buffer to disk (synchronous)" = "jbd2_journal_commit_transaction" latency events from showing, which is great. However, I still get high latency from other events in the system including "kworker/1:1 Executing raw SCSI command" and "kworker/u:7 - Fork() system call". These still cause drop-outs on my system. It looks like either the new stack is more sensitive to latency, or something else changed in the kernel between Fedora 14 and Fedora 15. I think my conclusion is that my problems are not caused by Ext4, but are something else... I will keep looking :O) Thanks for your help! A On Tue, Jul 12, 2011 at 12:17 PM, Theodore Tso <tytso@xxxxxxx> wrote: > > On Jul 11, 2011, at 8:07 PM, Andy Campbell wrote: > >> Hi ext4 mailing list members, >> >> I hope you can help me with a problem. >> >> I recently upgraded my main audio PC to Fedora FC15 and, at the same >> time, reformatted by root drive to ext4. Since this upgrade this, my >> system has high system latency which is causing my audio hardware >> (firewire) to experience buffer under-runs (XRUNs). This causes >> "unhandled xrun" errors and the audio software fails. > > What were you using before? ext3 ? It may be that ext4's default use of > barriers (for safety reasons) is causing a difference. Try mounting your > file systems with barrier=0. For the root filesystem, add "rootflags=barrier=0". > This is an unsafe way to run, in that if you have a power failure while you > are writing to the disk, your file system(s) could get corrupted. Ext3 > defaulted to this for historical reasons (although the enterprise Linux systems, > RHEL and SuSE changed the default for safety reasons). > > If this solves the problem, I'd suggest that you look into finding ways to > increase the buffer size of your audio system (were you recording or > doing playback at the time). You might also try to see if there was > some amount of disk activity (especially write activity) that could be > avoided or find some way of avoiding the use of fsync() so that you > can re-enable write barriers without causing your latency skips. > > Regards, > > -- Ted > > > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
