https://bugzilla.kernel.org/show_bug.cgi?id=16223 Summary: ext4 in data=journal mode does not support delayed allocation Product: File System Version: 2.5 Kernel Version: 2.6.34 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext4 AssignedTo: fs_ext4@xxxxxxxxxxxxxxxxxxxx ReportedBy: theosib@xxxxxxxxx Regression: No Perhaps you could argue that someone using data=journal mode doesn't care about write performance, but that would not necessarily be the case. It would be really nice if I could use ext4 with data journaling AND get delayed allocation. I'm just mentioning this because I'm probably not the only one out there with this feeling. In fact, I know I'm not because I've seen the question asked in forums. I suspect it might be nontrivial to modify the journaling system so that you can write data to the journal that has not yet been allocated a location on the disk, but it seems to me that's basically what you'd have to do. (Otherwise it wouldn't be DELAYED allocation, and we need data to hit the journal before it hits the fs proper.) Data would be written to the journal, then when it's going to be committed to the fs, it would be allocated (and that fact added to the journal?). If the system goes down, and a journal replay is required, then the data would be allocated space at that time. One thing to be concerned about is having an allocation happen, the data not written to where it's allocated, and the allocation not logged in the journal--on replay, you might allocate yet more space for the data, and you'd need some means to recover the first allocation that's now bogus. Thanks. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
