[Aleski, can you word wrap your email text at 72 columns? ] On Mon, Mar 12, 2018 at 10:01:54PM +0000, Besogonov, Aleksei wrote: > [snip unrelated] > > So I'm looking at the XFS code and it appears that the iomap is > limited to 1024*PAGE_SIZE blocks at a time, Take a closer look - that code is not used for reading file extents and returning them to the caller. > which is too small for > most of swap use-cases. I can of course just loop through the file > in 4Mb increments and, just like the bmap() code does today. But > this just doesn't look right and it's not atomic. And it looks > like iomap in ext2 doesn't have this limitation. > > The stated rationale for the XFS limit is: > >/* > > * We cap the maximum length we map here to MAX_WRITEBACK_PAGES pages > > * to keep the chunks of work done where somewhat symmetric with the > > * work writeback does. This is a completely arbitrary number pulled > > * out of thin air as a best guess for initial testing. > > * > > * Note that the values needs to be less than 32-bits wide until > > * the lower level functions are updated. > > */ Yeah, that's in the IOMAP_WRITE path used for block allocation. swap file mapping should not be asking for IOMAP_WRITE mappings that trigger extent allocation, so you should never hit this case. You should probably be using the IOMAP_REPORT path (i.e. basically very similar code to iomap_fiemap/iomap_fiemap_apply and rejecting any file that returns an iomap that is not IOMAP_MAPPED or IOMAP_UNWRITTEN. Also, you want to reject any file that returns IOMAP_F_SHARED in iomap->flags, too, because swapfiles can't do COW to break extent sharing on writes. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
