On Mon, Aug 29, 2016 at 08:57:41AM -0400, Theodore Ts'o wrote: > On Mon, Aug 29, 2016 at 12:41:16AM -0700, Christoph Hellwig wrote: > > > > We're going to move forward killing buffer_heads in XFS. I think ext4 > > would dramatically benefit from this a well, as would ext2 (although I > > think all that DAX work in ext2 is a horrible idea to start with). > > It's been on my todo list. The only reason why I haven't done it yet > is because I knew you were working on a solution, and I didn't want to > do things one way for buffered I/O, and a different way for Direct > I/O, and disentangling the DIO code and the different assumptions of > how different file systems interact with the DIO code is a *mess*. > > It may have gotten better more recently, but a few years ago I took a > look at it and backed slowly away..... Ted, what do you think of the idea of moving to struct iomap in ext2? If ext2 stays with the current struct buffer_head + get_block_t interface, then it looks like DAX basically has three options: 1) Support two I/O paths and two versions of each of the fault paths (PTE, PMD, etc). One of each of these would be based on struct iomap and would be used by xfs and potentially ext4, and the other would be based on struct buffer_head + get_block_t and would be used by ext2. 2) Only have a single struct iomap based I/O path and fault path, and add shim/support code so that ext2 can use it, leaving the rest of ext2 to be struct buffer_head + get_block_t based. 3) Only have a single struct buffer_head + get_block_t based DAX I/O and fault path, and have XFS and potentially ext4 do the translation from their native struct iomap interface. It seems ideal for ext2 to switch along with everyone else, if getting rid of struct buffer_head is a global goal. If not, I guess barring technical issues #2 above seems cleanest - move DAX to the new structure, and provide backwards compatibility to ext2. Thoughts? -- 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
