Re: [PATCH 8/9] Reimplement partition growing.

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

 



Hi,

On 10/29/2009 05:56 PM, David Lehman wrote:
Use Request and Chunk instances to calculate growth for all partitions,
then recreates and add the partitions to disk with new geometries.
---
  storage/partitioning.py |  591 ++++++++++++++++++++++++++++++++--------------
  1 files changed, 411 insertions(+), 180 deletions(-)

diff --git a/storage/partitioning.py b/storage/partitioning.py
index 9471513..1c02b6a 100644
--- a/storage/partitioning.py
+++ b/storage/partitioning.py

<snip>

+class Chunk(object):
+    """ A free region on disk from which partitions will be allocated """
+    def __init__(self, geometry, requests=None):
+        """ Create a Chunk instance.
+
+            Arguments:
+
+                geometry -- parted.Geometry instance describing the free space
+
+
+            Keyword Arguments:
+
+                requests -- list of Request instances allocated from this chunk
+
+        """
+        self.geometry = geometry            # parted.Geometry
+        self.pool = self.geometry.length    # free sector count
+        self.sectorSize = self.geometry.device.physicalSectorSize

This is wrong, parted's physicialSectorSize is for informational purposes only,
the geometry's alignemnts, etc. Are all expressed in logical sector sizes
(logical == the addressing which goes over the wire to the disk, physical ==
 addressing on the platter, so not really interesting).

Note that parted calls the logical sector size just plain sector size.

Note that your patch has this issue in multiple places, please fix them all.

+        self.base = 0                       # sum of growable requests' base
+                                            # sizes, in sectors
+        self.requests = []                  # list of Request instances
+        if isinstance(requests, list):
+            for req in requests:
+                self.addRequest(req)
+

<snip>

+            chunk.growRequests()
+
+            # recalculate partition geometries
+            disklabel = disk.format
+
+            start = chunk.geometry.start
+            #if start == 0 or start == getattr(extended_geometry, "start", 0):
+            #    start += 1
+
+            first_logical = False
+            if extended_geometry and chunk.contains(extended_geometry):
+                first_logical = True
+
+            new_partitions = []
+            for p in chunk.requests:
+                ptype = p.partition.partedPartition.type
+                log.debug("partition %s (%d): %s" % (p.partition.name,
+                                                     p.partition.id, ptype))
+                if ptype == parted.PARTITION_EXTENDED:
+                    continue
+
+                #if ptype == parted.PARTITION_LOGICAL:
+                #    # As you wish, parted.
+                #    start += 1
+
+                # XXX if the start of the extended is aligned then we must
+                #     burn one logical block to align the first logical
+                #     partition
+                if ptype == parted.PARTITION_LOGICAL and first_logical:
+                    start += _a.grainSize
+                    first_logical = False
+

Unfortunately, with extended partitions, we loose a grain size for every logical
partition. An extended partition looks like this (for example):

1 sector 1 entry partition table for 1st logical, with a pointer to the next table
xx sector logical
1 sector 1 entry partition table for 2nd logical, with a pointer to the next table
xx sector logical
1 sector 1 entry partition table for 3th logical, with a zero pointer indicating no more logicals follow
xx sector logical

So we need atleast 1 sector between each logical, now we can make the ending of the logicals
not aligned, but adding things like filesystem block size into the equasion this probably just means
we will still be loosing the space.

So I think this first_logical flag is not needed.

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