On 2/22/22 1:18 AM, Christoph Hellwig wrote: > On Sun, Feb 20, 2022 at 04:23:50AM +0000, Matthew Wilcox wrote: >> On Fri, Feb 18, 2022 at 11:35:10PM -0800, Christoph Hellwig wrote: >>> Err, hell no. Please do not add any new functionality to the legacy >>> buffer head code. If you want new features do that on the >>> non-bufferhead iomap code path only please. >> >> I think "first convert the block device code from buffer_heads to iomap" >> might be a bit much of a prerequisite. I think running ext4 on top of a >> block device still requires buffer_heads, for example (I tried to convert >> the block device to use mpage in order to avoid creating buffer_heads >> when possible, and ext4 stopped working. I didn't try too hard to debug >> it as it was a bit of a distraction at the time). > > Oh, I did not spot the users here is the block device. Which is > really weird, why would anyone do buffered writes to a block devices? > Doing so is a bit of a data integrity nightmare. > > Can we please develop this feature for iomap based file systems first, > and if by then a use case for block devices arises I'll see what we > can do there. The original plan wasn't to develop bdev async writes as a separate useful feature, but rather to do it as a first step to both become acquainted with the code base and solve some of the common issues for both. The fact that we need to touch buffer_heads for the bdev path is annoying, and something that I'd very much rather just avoid. And converting bdev to iomap first is a waste of time, exactly because it's not a separately useful feature. Hence I think we'll change gears here and start with iomap and XFS instead. > I've been planning to get the block device code to stop using > buffer_heads by default, but taking them into account if used by a > legacy buffer_head user anyway. That would indeed be great, and to be honest, the current code for bdev read/write doesn't make much sense outside of from a historical point of view. -- Jens Axboe
