On Sat 09-02-13 16:53:40, Ted Tso wrote: > I've been recently looking at journalling code in ext4, and it's clear > that no one has really been through this code in a while. It's easy to > find some easy optimization. > > Some general rules of thumb that developers should keep in mind when > making changes to ext4: > > 1) It's important to minimize the amount of time that a handle is held > active, since a journal commit can't be closed until all handles have > been stopped. In the ideal world, disk reads and memory allocations > should be done *before* calling ext4_journal_start(). > > 2) It's important that number of credits needed for a particular handle > be large enough; otherwise it's possible that we run out of space in the > journal without being able to finish the handle. > > 3) It's also important that we not overestimate then number of credits > needed, since otherwise we might close a transaction too early --- and > in particular, the process which starts the transaction commit process > will tend to suffer the greatest amount of latency. True but it's not too bad - we give back the credits we didn't use once the current handle is dropped. But if there are many handles open in parallel or if the overestimate is really huge, it will have visible effects. So I agree it's good to keep the estimate as close as resonably possible to reality. > Currently enabling quotas cause the number of credits required to > balloon significantly. Most of the time we need nowhere the number of > credits which we reserve, so there's opportunity to optimize things. > (For example, we could make sure create the quota record is created in a > seprate transaction.) So write(2) and similar calls are already optimized. You are right that create(2) or unlink(2) still overestimate needed credits only due to remotely possible worst case. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
