Steve Bergman <sbergman27 <at> gmail.com> writes: > Is this level of corruption expected behavior for delayed allocation? > Or have I hit a bug that needs to be reported to the ext4 guys? Should > delayed allocation be the default in an enterprise distribution which > does not, itself, make proper use of fsync? Should the risks of > delayed allocation be made more salient than they are to people who > upgrade from say, RHEL5 to RHEL6? Should options which trade data > integrity guarantees for performance be the defaults in any case? As > an admin, I don't care about benchmark numbers. But I care very much > about the issue of data endangerment "by default". There's quite a lot I could follow up on or correct in your previous couple emails, but here is a quick one: Delayed allocation is a technique which chooses a physical location for data when IO is sent to disk, not when the write() syscall is issued. There is nothing at all inherently dangerous about that mode of operation. ext4 may conflate this a little, because when delalloc is off, the old jbd 5-second-commit behavior is what starts pushing data out, rather than periodic writeback. But whether the filesystem chooses a physical block ahead of time or at the time of IO has no direct effect on safety or data integrity. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
