Comment 15 for bug 719129

On 02/17/2011 02:57 PM, Curtis Gedak wrote:
> In my testing I recall some GNU/Linux distributions as having both
> /dev/mapper and /dev/dm-# entries for the same dmraid device (and not
> symbolic links). Hence duplicate entries might already exist, even
> without using GParted. 'Just thought you might want to know that this
> situation can arise even without the use of GParted.

Not quite. One or other of those is a symlink. There is only one
actual device, so things like is it mounted checks follow the symlinks
and all check against the same bdev.

> Many users run GParted from a Live CD or USB image so that no
> partitions are mounted and the full capabilities of GParted are
> available. In this situation, the device naming does not matter to
> the GNU/Linux distributions on the hard disk device because the live
> image partition names disappear on reboot.

It matters if the partition is mounted, and then gparted makes a
completely separate block device show up that you can delete, and create
a new partition using that same space, despite the fact that the
original partition using that space is still mounted.

> To better understand your perspective, why are you concerned that
> GParted creates devices that follow the old dmraid naming standard?

I don't care WHICH standard is followed so much as that SOME standard is
obeyed by all components running in the system, so that the duplicate
device problem can be avoided. I think you have sold me though on the
'p' only when needed method that kpartx uses.

> The long term plan would be to remove DMRaid.cc. However to my
> knowledge (lib)parted versions that support dmraid have not been out
> for very long. Parted 2.3 was released on 28 May 2010, so it has not
> even been out for a year.

So why can't gparted releases from this year depend on libparted
versions also released this year?

> Parted versions 1.9.0 up to and including 2.2 have been out for longer
> but have experienced a critical problem to varying degrees. The
> critical problem is a failure to inform the kernel of partition
> changes. This causes grief when used with GParted.
> See:
> Problem Resizing File Systems with GParted
> http://gparted-forum.surf4.info/viewtopic.php?id=13777
> GParted contains a work-around for these earlier version,
> but it does not work 100% of the time.

This is the regression from dropping the BLKPG ioctl support and going
back to only BLKRRPART, so re-reading failed if any partition on the
drive was in use? I fixed that what? A year ago now?

> Hence if I am to change the minimum requirement of GParted to be
> libparted 2.3, then more time is needed for major GNU/Linux
> distributions to all be using at least this version or higher in the
> their currently supported releases.

Why? Who says a distribution needs to be able to run the latest version
of gparted, but an outdated version of libparted? If the distribution
can update to the latest version of gparted, then they can update parted
as well just as easily.

> Yes, compatibility with older versions of (lib)parted is desired for
> the reasons described above. I would suggest that this configuration
> option should automatically be set based on the (lib)parted
> version.

This could be done if desired, but really, why bother? Why not simply
put in the release notes that to use this latest version of gparted, you
need a version of parted released in the last year?

> If the goal is to have better support for dmraid devices in Natty, I
> would suggest that a more recent version of GParted be used.
> A problem with the dmraid path name was fixed in GParted 0.7.1:
> https://bugzilla.gnome.org/show_bug.cgi?id=634553

Can you be a bit more specific about related fixes since 0.7.0? Getting
an official dev to sponsor an update to a new upstream version this late
in the Natty cycle would require a good reason. I am sure I can get a
small patch in, but updating to a new upstream release requires
justification.

> The -P argument could be dropped; however, I think your idea to scan
> the output would then be required to determine what type of partition
> name was created by dmraid (e.g., with or without the 'p').

Scanning the output of dmraid would be a better general solution for
gparted to support multiple versions of dmraid, but is a much more
involved change, with more potential for regressions. Therefore, I
think I will just drop the -P argument for now, since within the scope
of Natty we know what version of dmraid we have and can control its
behavior, and I might take a look at a configure option to drop the
whole DMRaid.cc module and leave it all to libparted for Natty+1, and
submitting upstream patches for parted and dmraid to only add the 'p' if
the previous character is a digit instead of always. I will try to
coordinate with you closely so that if it is not merged upstream in time
for Natty+1, that it will at least have your approval so I can get it
into Natty+1 early in the cycle as a patch.