Quoting Steve French (2013-05-15 16:08:16) > On Wed, May 15, 2013 at 2:36 PM, Zach Brown <zab@xxxxxxxxxx> wrote: > > On Wed, May 15, 2013 at 12:50:13PM -0500, Steve French wrote: > >> Doesn't the new syscall have to invalidate the page cache pages that > >> the server is about to overwrite as btrfs does with the following line > >> in fs/btrfs/ioctl.c > >> > >> truncate_inode_pages_range(&inode->i_data, destoff, > >> PAGE_CACHE_ALIGN(destoff + len) - 1); > > > > The file_operations ->copy_range implementation is responsible for this, > > yeah, similar to ->write being responsible for invalidating around > > O_DIRECT writes. > > > >> (and doesn't truncate_inode_pages_range handle page cache alignment > >> anyway > > > > No, it bugs if given an end offset that isn't page aligned: > > > > BUG_ON((lend & (PAGE_CACHE_SIZE - 1)) != (PAGE_CACHE_SIZE - 1)); > > > > Lukas is working on a patch series to fix this: > > > > http://marc.info/?l=linux-fsdevel&m=136854986101843&w=2 > > > >> - and also why did btrfs use truncate_inode_pages_range instead > >> of invalidate?) > > > > I'm not sure. Maybe they can have racing dirty pages and want them > > thrown away rather than having invalidation fail? truncate_inode_pages_range ends with invalidate. It just locks the page first and makes sure to wait for writeback if it was already in progress. Looking at the btrfs side, I think we should add some locking on the destination extents as well. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
