On 03/24, Damien Le Moal wrote: > On Thu, 2023-03-23 at 16:46 -0700, Jaegeuk Kim wrote: > > On 03/23, Damien Le Moal wrote: > > > On Thu, 2023-03-23 at 15:14 -0700, Jaegeuk Kim wrote: > > > > On 03/20, Christoph Hellwig wrote: > > > > > On Mon, Feb 20, 2023 at 01:20:04PM +0100, Hans Holmberg wrote: > > > > > > A) Supporting proper direct writes for zoned block devices > > > > > > would > > > > > > be the best, but it is currently not supported (probably for > > > > > > a good but non-obvious reason). Would it be feasible to > > > > > > implement proper direct IO? > > > > > > > > > > I don't think why not. In many ways direct writes to zoned > > > > > devices > > > > > should be easier than non-direct writes. > > > > > > > > > > Any comments from the maintainers why the direct I/O writes to > > > > > zoned > > > > > devices are disabled? I could not find anything helpful in the > > > > > comments > > > > > or commit logs. > > > > > > > > The direct IO wants to overwrite the data on the same block > > > > address, > > > > while > > > > zoned device does not support it? > > > > > > Surely that is not the case with LFS mode, doesn't it ? Otherwise, > > > even > > > buffered overwrites would have an issue. > > > > Zoned device only supports LFS mode. > > Yes, and that was exactly my point: with LFS mode, O_DIRECT write > should never overwrite anything. So I do not see why direct writes > should be handled as buffered writes with zoned devices. Am I missing > something here ?
That's an easiest way to serialize block allocation and submit_bio when users are calling buffered writes and direct writes in parallel. :) I just felt that if we can manage both of them in direct write path along with buffered write path, we may be able to avoid memcpy. > > > > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
