Hi Eric, On 04/02/2013 12:00 AM, Eric Sandeen wrote: > On 4/1/13 10:39 AM, Theodore Ts'o wrote: >> On Mon, Apr 01, 2013 at 10:18:51AM -0500, Eric Sandeen wrote: >>> I'd add: >>> >>> 3) Why do we have a "nodelalloc" mount option at all? >>> >>> but then I thought: >>> >>> Is it also this bad when using the ext4 driver to run an ext3 fs? >> >> Yes, and I there would be a similar performance problem if you are >> using the ext3 file system driver, since ext3_*_writepage() also ends >> up calling block_write_full_page() which will also result in the >> writes happening with WRITE_SYNC. > >> The main reason why we keep nodelalloc at this point is bug-for-bug >> compatibility with ext3 file systems --- basically, for users who are >> using this as a workaround for the O_PONIES issue instead of fixing >> their applications to use fsync() appropriately. > > Sorry for getting off the original thread here, but IMHO these are > 2 different things: > > nondelalloc behavior makes sense for ext3, but: > -o nodelalloc mount options don't make sense for ext4. nodelalloc makes sense to me. In our product system, we met a latency problem that is caused by delalloc feature. The workload is a web app that does some append writes (approximately 5M/s), and wait flusher to do write out. We obverse that on every 30 seconds the latency will reach a high level (approximately 100-200ms or higher, but normally 10-20ms). The reason is that when flush tries to write dirty pages out, it will take i_data_sem lock (write lock) and allocate some blocks for these dirty pages. But in the mean time the app does some append write(2)s that will try to take i_data_sem lock (read lock) too. So the app will be delayed. So I think nodelalloc is still useful for us. Regards, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
