Suppose I have a large machine with 24Gig of memory, and I write a 2 gig file. This is below 10% and so background_dirty_threshold wont cause any write out. Suppose that a regular journal commit is then triggered. Am I correct in thinking this will flush out the full 2Gig, causing the commit to take about 30 seconds if the drive sustains 60Meg/second? If so, what other operations will be blocked while the commit happens? I assume sync updates (rm, chmod, mkdir etc) will block? Is it safe to assume that normaly async writes won't block? What about if they extend the file and so change the file size? What about atime updates? Could they ever block for the full 30 seconds? Supposing lots of stuff would block for 30seconds, is there anything that could be done to improve this? Would it be possible (easy?) to modify the commit process to flush out 'ordered' data without locking the journal? As you might guess, we have a situation where writing large files on a large-memory machine is causing occasional bad fs delays and I'm trying to understand what is going on. Thanks for any input, NeilBrown _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
