On Thu, Aug 05, 2021 at 11:19:17AM +0100, David Howells wrote: > I'm working on network filesystem write helpers to go with the read helpers, > and I see situations where I want to write a few bytes to the cache, but have > more available that could be written also if it would allow the > filesystem/blockdev to optimise its layout. > > Say, for example, I need to write a 3-byte change from a page, where that page > is part of a 256K sequence in the pagecache. Currently, I have to round the > 3-bytes out to DIO size/alignment, but I could say to the API, for example, > "here's a 256K iterator - I need bytes 225-227 written, but you can write more > if you want to"? I think you're optimising the wrong thing. No actual storage lets you write three bytes. You're just pushing the read/modify/write cycle to the remote end. So you shouldn't even be tracking that three bytes have been dirtied; you should be working in multiples of i_blocksize(). I don't know of any storage which lets you ask "can I optimise this further for you by using a larger size". Maybe we have some (software) compressed storage which could do a better job if given a whole 256kB block to recompress. So it feels like you're both tracking dirty data at too fine a granularity, and getting ahead of actual hardware capabilities by trying to introduce a too-flexible API.
