Message ID | cover.1537419652.git.osandov@fb.com (mailing list archive) |
---|---|
Headers | show |
Series | Btrfs: implement swap file support | expand |
On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote: > From: Omar Sandoval <osandov@fb.com> > Changes from v7 [1]: > > - Expanded a few commit messages > - Added Johannes' acked-by on patches 1 and 2 > - Rebased on v4.19-rc4 I've sent my comments, it's mostly about the usability or small enhancements. As you've got acks from MM people, I hope it would be ok if I add this series to for-next so we can give it some testing. The MM patches would better go separately to 4.20 via the mm tree. I did only build tests so 4.20 target is still feasible but given that it's rc4 it's a bit too close. There are some limitations posed by the swapfiles so I'd like to have a chance to do some actual tests myself and check the usability status.
On Thu, Sep 20, 2018 at 07:22:55PM +0200, David Sterba wrote: > On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote: > > From: Omar Sandoval <osandov@fb.com> > > Changes from v7 [1]: > > > > - Expanded a few commit messages > > - Added Johannes' acked-by on patches 1 and 2 > > - Rebased on v4.19-rc4 > > I've sent my comments, it's mostly about the usability or small > enhancements. As you've got acks from MM people, I hope it would be ok > if I add this series to for-next so we can give it some testing. That'd be great. Feel free to grab it from my git tree (https://github.com/osandov/linux/tree/btrfs-swap) if you want the version with your comments addressed. > The MM patches would better go separately to 4.20 via the mm tree. I > did only build tests so 4.20 target is still feasible but given that > it's rc4 it's a bit too close. There are some limitations posed by the > swapfiles so I'd like to have a chance to do some actual tests myself > and check the usability status. 4.20 would be nice, but I could live with 4.21. I'll just be backporting it to our internal kernel here anyways ;) Let me know how the tests go and which way you want to go. Thanks! It's nice to finally have the end in sight for this series, it's almost 4 years old, although it's changed quite a bit since https://lkml.org/lkml/2014/11/17/141.
On Thu, Sep 20, 2018 at 10:41:24AM -0700, Omar Sandoval wrote: > On Thu, Sep 20, 2018 at 07:22:55PM +0200, David Sterba wrote: > > On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote: > > > From: Omar Sandoval <osandov@fb.com> > > > Changes from v7 [1]: > > > > > > - Expanded a few commit messages > > > - Added Johannes' acked-by on patches 1 and 2 > > > - Rebased on v4.19-rc4 > > > > I've sent my comments, it's mostly about the usability or small > > enhancements. As you've got acks from MM people, I hope it would be ok > > if I add this series to for-next so we can give it some testing. > > That'd be great. Feel free to grab it from my git tree > (https://github.com/osandov/linux/tree/btrfs-swap) if you want the > version with your comments addressed. Updates looks good, branch added to the for-next snapshot and will be in upcoming for-next. > > The MM patches would better go separately to 4.20 via the mm tree. I > > did only build tests so 4.20 target is still feasible but given that > > it's rc4 it's a bit too close. There are some limitations posed by the > > swapfiles so I'd like to have a chance to do some actual tests myself > > and check the usability status. > > 4.20 would be nice, but I could live with 4.21. I'll just be backporting > it to our internal kernel here anyways ;) Let me know how the tests go > and which way you want to go. Backporting to your kernel is fine, your users will complain to you, but once it's in the mainline the complaints will go my way :) As for the merge of the non-btrfs patches, I checked again and there are the VFS/documentation patches that haven't been CCed to the relvant people. For that reason I'm not much comfortable to take them through my tree for the final merge. The MM part looks fine from that perspective.
On Fri, Sep 21, 2018 at 05:17:35PM +0200, David Sterba wrote: > On Thu, Sep 20, 2018 at 10:41:24AM -0700, Omar Sandoval wrote: > > On Thu, Sep 20, 2018 at 07:22:55PM +0200, David Sterba wrote: > > > On Wed, Sep 19, 2018 at 10:02:11PM -0700, Omar Sandoval wrote: > > > > From: Omar Sandoval <osandov@fb.com> > > > > Changes from v7 [1]: > > > > > > > > - Expanded a few commit messages > > > > - Added Johannes' acked-by on patches 1 and 2 > > > > - Rebased on v4.19-rc4 > > > > > > I've sent my comments, it's mostly about the usability or small > > > enhancements. As you've got acks from MM people, I hope it would be ok > > > if I add this series to for-next so we can give it some testing. > > > > That'd be great. Feel free to grab it from my git tree > > (https://github.com/osandov/linux/tree/btrfs-swap) if you want the > > version with your comments addressed. > > Updates looks good, branch added to the for-next snapshot and will be in > upcoming for-next. I got a kbuild error when building with CONFIG_SWAP=n, just pushed the fix below on patch 6: diff --git b/fs/btrfs/inode.c a/fs/btrfs/inode.c index ffe266e612e3..6de98bb30c27 100644 --- b/fs/btrfs/inode.c +++ a/fs/btrfs/inode.c @@ -10489,6 +10489,7 @@ void btrfs_set_range_writeback(struct extent_io_tree *tree, u64 start, u64 end) } } +#ifdef CONFIG_SWAP /* * Add an entry indicating a block group or device which is pinned by a * swapfile. Returns 0 on success, 1 if there is already an entry for it, or a @@ -10812,6 +10813,17 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file, sis->highest_bit = bsi.nr_pages - 1; return bsi.nr_extents; } +#else +static void btrfs_swap_deactivate(struct file *file) +{ +} + +static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file, + sector_t *span) +{ + return -EOPNOTSUPP; +} +#endif static const struct inode_operations btrfs_dir_inode_operations = { .getattr = btrfs_getattr, > > > The MM patches would better go separately to 4.20 via the mm tree. I > > > did only build tests so 4.20 target is still feasible but given that > > > it's rc4 it's a bit too close. There are some limitations posed by the > > > swapfiles so I'd like to have a chance to do some actual tests myself > > > and check the usability status. > > > > 4.20 would be nice, but I could live with 4.21. I'll just be backporting > > it to our internal kernel here anyways ;) Let me know how the tests go > > and which way you want to go. > > Backporting to your kernel is fine, your users will complain to you, but > once it's in the mainline the complaints will go my way :) > > As for the merge of the non-btrfs patches, I checked again and there are > the VFS/documentation patches that haven't been CCed to the relvant > people. For that reason I'm not much comfortable to take them through > my tree for the final merge. The MM part looks fine from that > perspective. There aren't any VFS changes, just the trivial documentation fixes. fsdevel was Cc'd for the first four versions, but it's hard enough to get Al to look at actual changes, let alone a documentation fix.
From: Omar Sandoval <osandov@fb.com> Hi, This series implements swap file support for Btrfs. Changes from v7 [1]: - Expanded a few commit messages - Added Johannes' acked-by on patches 1 and 2 - Rebased on v4.19-rc4 No functional changes. Thanks! 1: https://www.spinics.net/lists/linux-btrfs/msg81933.html Omar Sandoval (6): mm: split SWP_FILE into SWP_ACTIVATED and SWP_FS mm: export add_swap_extent() vfs: update swap_{,de}activate documentation Btrfs: prevent ioctls from interfering with a swap file Btrfs: rename get_chunk_map() and make it non-static Btrfs: support swap files Documentation/filesystems/Locking | 17 +- Documentation/filesystems/vfs.txt | 12 +- fs/btrfs/ctree.h | 29 +++ fs/btrfs/dev-replace.c | 8 + fs/btrfs/disk-io.c | 4 + fs/btrfs/inode.c | 317 ++++++++++++++++++++++++++++++ fs/btrfs/ioctl.c | 31 ++- fs/btrfs/relocation.c | 18 +- fs/btrfs/volumes.c | 82 ++++++-- fs/btrfs/volumes.h | 2 + include/linux/swap.h | 13 +- mm/page_io.c | 6 +- mm/swapfile.c | 14 +- 13 files changed, 502 insertions(+), 51 deletions(-)