Andreas Dilger wrote:
On Aug 24, 2009 09:34 -0400, Theodore Ts'o wrote:
On Mon, Aug 24, 2009 at 10:33:10AM +0200, Christian Fischer wrote:
I try to figure out reasonable mount options for ext4.
I've seen a "Enable asynchronous commits by default" patch from Sun, 21 Sep
2008.
Why is it revoked?
It patch was never merged because the ayschronous commits feature
disabled all write barriers, so under heavy workloads a power failure
could cause data loss.
No one has gotten around to looking at this closely; I think adding a
strategically placed blkdev_issue_flush() will allow us to safely
enable this feature, but it needs careful study.
I don't think that was the issue, but rather that we wanted to have
per-block checksums in order to handle the case were some block in
transaction A is causing a transaction checksum failure, yet transaction
B has already committed and begun checkpointing.
One option discussed was to add a lightweight 16-bit checksum (e.g. TCP
checksum) to the high bits of the t_flags of the block tag. The checksum
doesn't have to be very strong since the whole-transaction checksum will
be the primary point of validation.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
I still don't trust the logic. Seems like a very complex (and really
non-intuitive - async and commit, really?) thing to support for a
marginal performance impact. Any blkdev_issue_flush() call would dwarf
the advantage of the async bit of the commit.
If we are looking to better support workloads that suffer from
journalling, I suspect that we have more natural ways to do that...
ric
--
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
