WIP: Initial Stratis support

[vojtechtrefny]

This adds just a basic support for Stratis devices. Information about stratis blokdevs, pools and filesystems is gathered using the Stratis DBus API. I've added two new devices (StratisFilesystemDevice and StratisPoolDevice) and a new format (StratisBlockdev) with just few stratis specific properties for now. This is definitely not finished, I'm posting it here just to get some feedback about the "design" decisions, naming etc.

Stratis devices in devicetree

existing 1024 MiB disk sdc (304) with existing stratis
  existing 2 GiB stratis_pool stratis_howto (313)
    existing 1024 GiB stratis_filesystem stratis_howto/fs_howto2 (317) with existing xfs filesystem
    existing 1024 GiB stratis_filesystem stratis_howto/fs_howto (327) with existing xfs filesystem
existing 1024 MiB disk sdb (338) with existing stratis
  existing 2 GiB stratis_pool stratis_howto (313)
    ...

Stratis filesystem device

StratisFilesystemDevice instance (0x7f6d3c2fe8b0) --
  name = stratis_howto/fs_howto  status = True  id = 327
  children = []
  parents = ['existing 2 GiB stratis_pool stratis_howto (313)']
  uuid = 2d3dd8a9c7fe4217a792a0ca0bae5d24  size = 1024 GiB
  format = existing xfs filesystem
  major = 0  minor = 0  exists = True  protected = False
  sysfs path = /sys/devices/virtual/block/dm-12
  target size = 1024 GiB  path = /stratis/stratis_howto/fs_howto
  format args = []  original_format = xfs

Stratis pool device

StratisPoolDevice instance (0x7f6d3c2fe6a0) --
  name = stratis_howto  status = True  id = 313
  children = ['existing 1024 GiB stratis_filesystem stratis_howto/fs_howto2 (317) with '
 'existing xfs filesystem',
 'existing 1024 GiB stratis_filesystem stratis_howto/fs_howto (327) with '
 'existing xfs filesystem']
  parents = ['existing 1024 MiB disk sdc (304) with existing stratis',
 'existing 1024 MiB disk sdb (338) with existing stratis']
  uuid = f9eb3e81d0c04f9fb28db24365e4f754  size = 2 GiB
  format = existing None
  major = 0  minor = 0  exists = True  protected = False
  sysfs path = 
  target size = 2 GiB  path = /stratis/stratis_howto
  format args = []  original_format = None

[vojtechtrefny]

Can we expect this to be always 1 TiB? We need the size just for the initial device scan, it is later updated from sysfs.

[jbaublitz]

Currently, you can expect this to always start as 1 TiB. It will grow if the physical storage available is greater than 1 TiB and the filesystem fills up. Stratis automatically extends the filesystem size when it fills up. Currently, resizing will double the filesystem size.

[jbaublitz]

A few notes about the interface design that we have. Because we try to be as backwards compatible as possible, these interface names should still be available in Stratis v2.x, but just a note that these are the oldest interfaces available. These will probably need to be updated as new Fedora releases include later versions of stratisd.

[mulkieran]

jbaublitz is correct. You'll generally want the most recent revision for the version of stratisd that is available.

[vojtechtrefny]

I've used these interfaces mostly because I didn't need any properties from the newer revisions, but I'll try to use the newest interfaces in the future.

[jbaublitz]

I'll do a more thorough look through after I've discussed with the team, but this overall looks like a really good starting point!

[mulkieran]

Looks fine!

[vojtechtrefny]

I've pushed an updated version which includes a special class for the XFS filesystem on Stratis -- it's basically XFS with _create and _destroy functions overridden to be no-op. I think it's way better solution that having the workaround to not remove/create filesystem on Stratis FS devices, it makes the low level API a little bit confusing but we are already doing something similar for Btrfs and no one should create the devices manually anyway, we have helper functions for that. The new stratis_xfs filesystem type looks weird, but it shouldn't cause any issues. Thoughts @dwlehman? This still doesn't contain encryption or devicefactory support, but these shouldn't affect the lower level device and format implementation.

[vojtechtrefny]

I've pushed (I hope) last version of the encrypted pools support and this should be now ready for review. The only missing part (I know about) is the size limits/free space calculation for pools. Stratis team is working on a tool that will allow us to calculate these limits for non-existing pools (see stratis-storage/stratisd#2513).

With the encrypted pools support, I've tried to hide as much of the internal structure as possible. For both locked and unlocked pools, the LUKS format and device are hidden and internally we pretend the LUKS device is actually a Stratis block device

Unlocked pool:

existing 10 GiB disk vdb (38) with existing msdos disklabel
  existing 10 GiB partition vdb1 (48) with existing stratis
    existing 10 GiB stratis_pool blivet (57)

Locked pool:

existing 10 GiB disk vdb (38) with existing msdos disklabel
  existing 10 GiB partition vdb1 (48) with existing stratis

This makes populator helpers for stratis and LUKS a little bit messy but I think it's worth it and makes the stratis encrypted devices easier to present to users.

I'm also working on blivet-gui support for Stratis (storaged-project/blivet-gui#277) to test these changes and also to make sure the API makes sense from the user point of view.