On Sun, Jan 20, 2013 at 03:35:21PM -0700, Dave Chinner wrote: > On Fri, Jan 18, 2013 at 06:01:28PM -0500, Theodore Ts'o wrote: > > .... and can we get rid of this horrible hack where we have this > > bastardized use of a struct buffer_head which is allocated on the > > stack, which has nothing really to do with a buffer head, and is all > > about the fact that no one wants to change the function signature for > > get_block_t? > > I have patches to do that, but they are on the back burner right now > because it causes some kind of weird corruption in the pwritev case > that kvm uses to issue IO (i.e. large iovecs of 4k segments). > > IMO, the direct IO code is that complex and convoluted now that t is > close to impossible to modify without introduce some weird, subtle > and almost impossible to debug issue. The code has been optimised to > the point of being unmaintainable, and I have seriously considered > just reimplementing the bits XFS needs just for XFS several times in > the past year.... > Yeah this is the point that I'm at currently, and it's even worse for Btrfs since we have to short circuit most of the work that the generic stuff does already since we build bio's ourselves. So maybe it would be best that we trim the generic stuff down to it's most basic functionality and leave it in place for things like ext2/3, and then for the more advanced file systems we just all do our own things. If we can all take a good look at what we would need to replace maybe we can come up with some generic helpers. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
