Re: [PATCH 4/6] Make PartitionDevice have its own teardown()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 01/21/2010 01:03 AM, Peter Jones wrote:
This makes PartitionDevice.teardown() remove device-mapper tables when
appropriate, so devices using them don't have to clean up the partition
and all the conditional testing that comes with that.
---
  storage/devices.py |   19 +++++++++++++++++++
  1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/storage/devices.py b/storage/devices.py
index 3bb0991..237fc75 100644
--- a/storage/devices.py
+++ b/storage/devices.py
@@ -1314,6 +1314,25 @@ class PartitionDevice(StorageDevice):

          self.exists = False

+    def teardown(self, recursive=None):
+        """ Close, or tear down, a device. """
+        log_method_call(self, self.name, status=self.status)
+        if not self.exists and not recursive:
+            raise DeviceError("device has not been created", self.name)
+
+        if self.status:
+            if self.format.exists:
+                self.format.teardown()
+            devmap = block.getMap(major=self.major, minor=self.minor)
+            if devmap:
+                try:
+                    block.removeDeviceMap(devmap)
+                except Exception as e:
+                    raise PartitioningError("failed to tear down device-mapper partition %s: %s" % (self.name, e))
+
+            udev_settle()
+        StorageDevice.teardown(self, recursive=recursive)
+

Erm this is going to be a problem for dmraid, if you do this you should also add a modified setup()
which restores the partitions again, because nothing else is going to do that for dmraid sets.

But I wonder, are there reasons to take the mpath set down once up ? With BIOS RAID (both the mdraid
and dmraid flavors) I started out implementing setup() and teardown() methods too. But in the end
it turned out it was better to just set them up once, and be done with it (partition handling problems
was one of the reasons to do this, pyblock and parted both modifying the partition mappings in turn
got ugly pretty quickly).

So currently for dmraid the model is:

1) Assemble it using pyblock, which creates the initial partition mappings
2) Don't let pyblock do anything else with it
3) Let parted modify the mappings as it adds / removes partitions
   (when executing actions).

You're above patch breaks this as, once the teardown removes the partition nothing
is going to restore it. Also keep in mind that certain actions, only setup and
teardown a single device. So you cannot count on the disk setup() restoring the
partition mappings, if you are going to do this you need to add a setup() which
restores the mapping. But I think using the dmraid model instead is better.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux