On 07/03/2013 11:37 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:27 -0400, Ric Wheeler wrote:
On 07/03/2013 11:22 AM, James Bottomley wrote:
On Wed, 2013-07-03 at 11:04 -0400, Ric Wheeler wrote:
Why not have the atomic write actually imply that it is atomic and durable for
just that command?
I don't understand why you think you need guaranteed durability for
every journal transaction? That's what causes us performance problems
because we have to pause on every transaction commit.
We require durability for explicit flushes, obviously, but we could
achieve far better performance if we could just let the filesystem
updates stream to the disk and rely on atomic writes making sure the
journal entries were all correct. The reason we require durability for
journal entries today is to ensure caching effects don't cause the
journal to lie or be corrupt.
Why would we use atomic writes for things that don't need to be
durable?
Avoid a torn page write seems to be the only real difference here if
you use the atomic operations and don't have durability...
It's not just about torn pages: Journal entries are big complex beasts.
They can be megabytes big (at least on xfs). If we can guarantee all or
nothing atomicity in the entire journal entry write it permits a more
streaming design of the filesystem writeout path.
James
Journals are normally big (128MB or so?) - I don't think that this is unique to xfs.
If our existing journal commit is:
* write the data blocks for a transaction
* flush
* write the commit block for the transaction
* flush
Which part of this does and atomic write help?
We would still need at least:
* atomic write of data blocks & commit blocks
* flush
Right?
Ric
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
