Using different RAID types for metadata and data

phillxnet · August 31, 2018, 11:46am

@vesper1978 Thanks for posting / looking into this one.

That bit of code only retrieves the existing raid level (get) and is used to inform the pool model of what actually exists.

Well done digging them out by the way.

There are a few other places, mainly when changing raid levels, that would need changing. Not impossible but would need a fair bit of rigour to make sure we don’t break anything as the project has always assumed they are both set equally, with the odd caveat: as ‘quoted’.

@KarstenV I had seen the discussion of the btrfs mailing list re accompanying parity data raid with raid1 metadata. This is an interesting idea and maybe we could offer a kind of custom setting which equates to this. But again this may require a model change or an across the board change in how we represent and read/confirm existing raid levels.

There is also the unit test for the strangely named ‘pool_raid’ here:

github.com

rockstor/rockstor-core/blob/master/src/rockstor/fs/tests/test_btrfs.py#L61-L70


      
          
          def setUp(self):
              self.patch_run_command = patch("fs.btrfs.run_command")
              self.mock_run_command = self.patch_run_command.start()
              # # setup mock patch for is_mounted() in fs.btrfs
              # self.patch_is_mounted = patch('fs.btrfs.is_mounted')
              # self.mock_is_mounted = self.patch_is_mounted.start()
              # setup mock patch for mount_root() in fs.btrfs
              self.patch_mount_root = patch("fs.btrfs.mount_root")
              self.mock_mount_root = self.patch_mount_root.start()

That might be the best place to start re code changes as then we know we can at least correctly retrieve this mixed scenario. We could then track the entire treatment of raid levels through the code and ensure we can deal with splitting the data and metadata levels. Bit of a job and in the critical path so not really a priority, at least for me, currently but we could edge up to this.

What are the thoughts on simply offering 2 additional levels, as a first off, ie raid5/meta1 and raid6/meta1. This way can more easily maintain the ‘ease of use’ element of simplifying the raid levels presentation, while at the same time extending our capabilities. Fair bit of work there but definitely doable.

Agreed, any takers for drawing up the changes needed as a start. Remember to take into account the limitations we place on raid level conversions. These have been established by experimentation and would need to be re-tested with these 2 additional ‘levels’. And we would need to carry through to all UI elements the, initially twin, values of data and metadata.

Also note the start_balance single element ‘convert’ which would have to become a little more sophisticated, ie maybe a tuple.

github.com

rockstor/rockstor-core/blob/master/src/rockstor/fs/btrfs.py#L1407-L1427


      
                  return -1
              # if no exception, and no caught WARNING, find the max 2015/qgroup
              res = 0
              for l in o:
                  if re.match("{}/".format(QID), l) is not None:
                      cid = int(l.split()[0].split("/")[1])
                      if cid > res:
                          res = cid
              return res
          
          
          def qgroup_create(pool, qgroup=PQGROUP_DEFAULT):
              """
              When passed only a pool an attempt will be made to ascertain if quotas are
              enabled, if not '-1/-1' is returned as a flag to indicate this state.
              If quotas are enabled then the highest available quota of the form
              2015/n is selected and created, if possible (Read-only caveat).
              If passed both a pool and a specific qgroup an attempt is made, given the
              same behaviour as above, to create this specific group: this scenario is
              primarily used to re-establish prior existing qgroups post quota disable,
              share manipulation, quota enable cycling.

All doable but we have to tread carefully here as this code has taken ages to stabilise.

That may have been in the tread posted here:

Hope that helps and I’m in principle in favour of this capability being adding, but I’d like to keep things simple as most will be best sticking to the basic defaults and too much mixing of raid levels could get pretty messy, ie when working out the minimum drive count requirement and raid level changes etc.

Maybe ideas on how this might be presented / represented to the user. I favour the simple approach first but would welcome a UI representation of at least the data and metadata and that shouldn’t be too much more complexity (hopefully).