Thanks to all for ideas and corrections for my original patch. I'd like to
summarize the issues that I've seen raised:
1. Using blockdev_direct_IO_own_locking() as it stands, without additional
locking in the ext4 code, is incorrect.
2. The conversion from uninit to initialized extents should be done in an IO
completion handler.
3. When the uninit-to-init extents are converted, the handle must be marked
as synchronous.
But this will make DIO writes (to fallocated space) with a journal have
bad performance.
4. Ted mentioned some optimizations possible for extent conversion (when the
extent block isn't part of a transaction, and no new block is required).
Jan says that verifying that the extent block is not part of a
transaction can be difficult.
Also we could increase the extent size that we're willing to zero out the
data blocks for.
5. Aneesh mentioned that we could use extent tracking a la Chris Mason's
patch for data=guarded (I confess, I haven't looked at this yet).
6. Jan's other thought is to use a new ext4_get_blocks_direct() routine as
the get_block callback to blockdev_direct_IO() -- so no use of
_own_locking(). This would simply return blocks from uninit extents;
extent conversion (including possible splitting) would then be done in
ext4_direct_IO().
7. Ted's last comment is about the tradeoffs between getting the journal
transaction correct vs aggressive zeroout of data blocks -- seeing if
it's possible to bypass the journal in the case of preallocated DIO
writes.
Looking through these, it seems to me that there are two major problems:
a. How to correctly do extent conversion in the face of locking issues and
races with other requests (e.g. AIO)
b. How to efficiently do this extent conversion in the face of correct
journal semantics.
Have I missed anything?
Jan's idea of a new get_block callback for DIO seems like the simplest
solution to (a) above. No locking changes would seem to be needed, I think.
Does this seem reasonable?
Problem (b) is one that I would defer to others with more experience with
journals than I have.
Thanks,
Curt
--
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
