[v8,0/6] Btrfs: implement swap file support
mbox series

Message ID cover.1537419652.git.osandov@fb.com
Headers show
Series
  • Btrfs: implement swap file support
Related show

Message

Omar Sandoval Sept. 20, 2018, 5:02 a.m. UTC
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(-)

Comments

David Sterba Sept. 20, 2018, 5:22 p.m. UTC | #1
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.
Omar Sandoval Sept. 20, 2018, 5:41 p.m. UTC | #2
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.
David Sterba Sept. 21, 2018, 3:17 p.m. UTC | #3
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.
Omar Sandoval Sept. 21, 2018, 6:29 p.m. UTC | #4
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.